https://bugzilla.wikimedia.org/show_bug.cgi?id=21033
Roan Kattouw <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #1 from Roan Kattouw <[email protected]> 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 -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
