Last modified: 2012-04-19 21:43:04 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>>
All the links should focus the cursor before first '=' sign.
please refer the attachment for more details.
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
Cookies Enabled: Enabled
Java Enabled: Enabled
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
Should be fixed in r57492.
Verified and Passed
Verified and Passed