Last modified: 2011-01-25 00:26:18 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 17240 - history.js blocks gecko browser (firefox 3.5) with 100% CPU when rendering long history
history.js blocks gecko browser (firefox 3.5) with 100% CPU when rendering lo...
Status: RESOLVED DUPLICATE of bug 19287
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
1.15.x
All All
: Normal major with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
http://pl.wikipedia.org/w/index.php?t...
:
Depends on:
Blocks: 1381
  Show dependency treegraph
 
Reported: 2009-01-30 04:10 UTC by Marcin Cieślak
Modified: 2011-01-25 00:26 UTC (History)
6 users (show)

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


Attachments

Description Marcin Cieślak 2009-01-30 04:10:09 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.
Comment 1 Mike.lifeguard 2009-01-30 04:14:14 UTC
(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.
Comment 2 Marcin Cieślak 2009-01-30 04:16:26 UTC
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:)
Comment 3 Brion Vibber 2009-01-30 21:41:47 UTC
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. :)
Comment 4 Nux 2009-02-01 18:03:48 UTC
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.
Comment 5 Jorge Stolfi 2009-04-12 21:50:14 UTC
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
Comment 6 xenocidic 2009-04-13 15:52:53 UTC
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.

Comment 7 RockMFR 2009-04-13 20:07:02 UTC
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.
Comment 8 Marcin Cieślak 2009-04-13 21:18:51 UTC
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?
Comment 9 Brion Vibber 2009-06-23 01:46:13 UTC
*** Bug 19287 has been marked as a duplicate of this bug. ***
Comment 10 Mike.lifeguard 2009-07-19 20:14:43 UTC
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 ***

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


Navigation
Links