Last modified: 2011-01-25 00:26:18 UTC
CSS restyling code in most of the gecko-based browsers (in the FrameManager::ReResolveStyleContext for the curious, see https://developer.mozilla.org/En/Style_System_Overview) when displaying a history page with larger number of revisions. Everything is fine when histrowinit() from history.js is not loaded, i.e removing the hook or blocking history.js load relieves the situation. The problem occurs only at initial page load, further clicks on the history page do not slow down the browser.
(In reply to comment #0) > CSS restyling code in most of the gecko-based browsers (in the > FrameManager::ReResolveStyleContext for the curious, see > https://developer.mozilla.org/En/Style_System_Overview) when displaying a > history page with larger number of revisions. > > Everything is fine when histrowinit() from history.js is not loaded, i.e > removing the hook or blocking history.js load relieves the situation. > > The problem occurs only at initial page load, further clicks on the history > page do not slow down the browser. > This can (and does) crash the whole browser in at least some cases.
The workaround is to put removeHandler(window, 'load', histrowinit); in your skin.js (i.e. Special:Mypage/monobook.js) file and kill the cache (pointy hat to Splarka:)
This doesn't seem particularly slow in Firefox 3.0.6b1, but I can confirm it's insanely slow in a 3.1b nightly. Is this a regression in Gecko? If so it should be taken care of upstream -- though if we can improve our code's own performance that would be good. :)
Hm... An easy (and maybe best) fix would be to do initial page setup on the server side. All of checkboxes on the right should be hidden with a CSS class that hides thing when JS is available. This is quite easy to do just add in a header something like: <!-- with and without JS visibility --> <style type="text/css"> .withJSvisible {visibility: hidden} </style> <script language="JavaScript" type="text/javascript"> document.write(String.fromCharCode(60),'style type="text/css"',String.fromCharCode(62), '.withJSvisible {visibility:visible !important} ', '.withoutJSvisible {visibility:hidden !important} ', String.fromCharCode(60),'/style',String.fromCharCode(62) ); </script> Then just add class="withoutJSvisible" to all inputs (checkboxes) on the right except the top one. Then only thing left would be to mark active li elements, but at start those are always the first two so it's independent of the page length.
Sorry to ask, but --- will this bug be fixed eventually, or am I expected to fix it by editing my profile somehow? (I use the standard MonoBook skin with Firefox 3.0.8/Gecko 2009033116) All the best, --stolfi
This is occuring on en.wiki now, for the last few days, see http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#History_pages_taking_forever_to_load_with_javascript_enabled and http://en.wikipedia.org/wiki/Wikipedia:VPT#Hanging_in_firefox @Jorge Stolfi, the workaround described above by Marcin Cieślak at 2009-01-30 04:16:26 UTC works for me.
The problem at enwiki was caused by the following line being added to our Common.css: .ambox + .ambox { margin-top: -1px; } The use of the adjacent selector without specifying an element name seems to be what caused the problem. plwiki has some similar stuff in its Common.css.
Removing some adjacent selectors (on plwiki actually not related to "ambox") did help to work-around the issue. Is this reported on https://bugzilla.mozilla.org/ already?
*** Bug 19287 has been marked as a duplicate of this bug. ***
I guess I'll mark this as a dupe of bug 19287, which has been fixed. *** This bug has been marked as a duplicate of bug 19287 ***
