Last modified: 2010-06-13 18:28:54 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 14585 - wikibits/insertTags issue on Opera 9.5
wikibits/insertTags issue on Opera 9.5
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
1.12.x
PC Windows XP
: Normal normal with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: javascript
  Show dependency treegraph
 
Reported: 2008-06-18 18:57 UTC by Peter Cooper Jr.
Modified: 2010-06-13 18:28 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Peter Cooper Jr. 2008-06-18 18:57:53 UTC
On Opera 9.5 (on Windows at least), clicking on a letter or tag to insert it on the editing page inserts the character or tag correctly, but then moves the text cursor to the beginning of the text box. I believe that on previous versions of Opera, and in other browsers, it correctly left the text cursor after the inserted text such that one could click on more than one symbol or tag to be inserted.

I don't know if it's an Opera issue or a MediaWiki issue, but I'd appreciate it if somebody more familiar with the insertTags function looked at it.

Thank you.
Comment 1 Christian Thiele 2008-07-03 19:55:22 UTC
The problem is the following (the code could be found in edit.js, function insertTags). 

With "range.text = tagOpen + selText + tagClose;" the new text is set and the cursor is set after the new text, so up to this point it's correct. But then "range.select();" is called. It's nothing selected at this time, so the cursor is set to the beginning. Normally the text should be selected again using the code between these two lines, but this doesn't work. So the first fix would be to put "range.select();" into the block "if (isSample && range.moveStart)". This line has to be in this block.

But this wouldn't fix the problem: the text should be selected again using this block and Opera doesn't go into this block, because "isSample" is false. "isSample" should be set to true using "checkSelectedText()", a subroutine of "insertTags()". The corresponding line seems to be executed, but the value isn't set. This seems to be a problem of global/local variables... the line "selText = sampleText;" is executed, too but "selText" doesn't change. I don't know the details of JavaScript and validity of variables, but this is the problem... 
Comment 2 Piotr Kubowicz 2008-09-01 12:37:00 UTC
I'm using newest stable version of Opera - 9.52 - and edit buttons work fine. I suggest closing the bug.
Comment 3 Christian Thiele 2008-09-01 13:10:38 UTC
This is true. Opera 9.52 has the same behavior like current Firefox and IE versions, so this seems to be correct now.
Comment 4 AlexSm 2008-09-30 14:56:52 UTC
As far as I can see, this was a bug in Opera 9.50 and Opera 9.51. 

Suggest closing.

To #1: range.select() is necessary for IE to make the selection visible again.
Comment 5 Max Semenik 2010-06-13 18:28:54 UTC
Closing the bug, the affected versions of Opera were responsible for 0.06% of hits last month per http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links