Last modified: 2012-04-19 21:43:04 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 21033 - Navigable TOC : Cursor moves to wrong position on Safari 3.2
Navigable TOC : Cursor moves to wrong position on Safari 3.2
Status: CLOSED FIXED
Product: MediaWiki extensions
Classification: Unclassified
UsabilityInitiative (Other open bugs)
unspecified
PC Windows Vista
: Normal major (vote)
: ---
Assigned To: Trevor Parscal
http://prototype.wikimedia.org/deploy...
:
Depends on:
Blocks: 36111
  Show dependency treegraph
 
Reported: 2009-10-07 10:05 UTC by Calcey QA
Modified: 2012-04-19 21:43 UTC (History)
2 users (show)

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


Attachments
Bug desc screen shots (474.78 KB, application/pdf)
2009-10-07 10:05 UTC, Calcey QA
Details

Description Calcey QA 2009-10-07 10:05:47 UTC
Created attachment 6639 [details]
Bug desc screen shots

Reporting against build r57304

Steps to reproduce :
1) Start editing a new page.
2) Enter following texts into text area.
==Heading text 1==
===Heading text 2===
====Heading text 3====
=====Heading text 4=====
3) Click links in the navigable TOC one by one.
<<Available 4 links focuses deferent positions when click on them>>

Expected Outcome::
All the links should focus the cursor before first '=' sign.

please refer the attachment for more details.

Test Environment:
Browser (User-Agent):	Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/525.27.1 (KHTML, like Gecko) Version/3.2.1 Safari/525.27.1
Time and Date:	3:22:51 PM - Wednesday, October 07, 2009
Javascript:	Enabled
Cookies Enabled: Enabled
Java Enabled:	Enabled
Comment 1 Roan Kattouw 2009-10-07 12:22:58 UTC
This looks like a newline handling issue, as described at http://bit.ly/9gSqt (but for Opera). Trevor, could you look at the following things?
1. Whether this bug can be reproduced on all supported versions of Safari, or only some old ones
2. Whether $.isOperaBroken is set to true or false (should be set when NTOC is fully initialized; run $j.wikiEditor.fixOperaBrokenness('') to set it manually if need be)
3. In exactly which way Safari's newline handling is broken

Expected answers (i.e. the answers you'd get if my theory based on the attached screenshot is right):
2. false. In the part of $.wikiEditor.fixOperaBrokenness() that tests for Opera-like newline brokenness, I expect textarea.val() to end in "bBAR". While that result indicates brokenness, it does pass the Opera-specific test textarea.val().substr(-1) == 'R' (Opera generates a string ending in "BARr" here). You can verify this by commenting out the lines that involve .height(), .width() or .remove()
3. Safari is broken in a way that's the exact opposite of Opera's: in textarea.val() newlines are two characters, but when working with selections (using textarea.setSelection()) they're treated as one character
Comment 2 Roan Kattouw 2009-10-07 21:36:41 UTC
Should be fixed in r57492.
Comment 3 Calcey QA 2009-10-13 08:13:56 UTC
Verified and Passed
Comment 4 Calcey QA 2009-10-13 08:15:02 UTC
Verified and Passed

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


Navigation
Links