Last modified: 2013-11-07 18:25:23 UTC
Created attachment 12947 [details] Firefox - Detected script lockup. Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28 Steps to reproduce: - Navigate to [[Lauda Air Flight 004]] and open it with the visual editor. - Click the "Lauda Air Flight 004" infobox and make sure it remains selected. - Click the "Bulleted List" button. A list bullet is added to the article. - Click right after the bullet that was just inserted. Now click the "Bulleted list" button again. Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes) In practice one would never want to add a bulleted list this way, but actually "crashing" makes it severe enough to report i would assume.
We should have a 'crash' or 'dataloss' keyword. Bumping priority to get more attention/triaging in case the underlying cause is able to be triggered in other ways.
This is an infinite loop inside either Rangy or the bit of ContentEditable that calls it - lots of calls to sel.getRangeAt(index) which end up taking so long that the browser dies (?)
Cannot reproduce it now with MAC OS using FireFox and Chrome.So changing the status of the bug as resolved. If you can still reproduce it ,please reopen the bug.
(In reply to comment #3) > Cannot reproduce it now with MAC OS using FireFox and Chrome. Please ALWAYS provide version information for browsers. Note that comment 0 says "Tested on both Firefox 22 and Chrome 28". > So changing the status of the bug as resolved. No identifiable code commit, hence changing to WORKSFORME instead of FIXED. Also see https://www.mediawiki.org/wiki/Bug_management/Bug_report_life_cycle
Resetting to FIXED; this was a confirmed broken behaviour which has subsequently been FIXED, as far as we can tell - probably by the re-write of the Content Editable surface interaction model.
