Last modified: 2013-11-02 11:52:01 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 49935 - Browser freezes on loading a large page with UniversalLanguageSelector (ULS)
Browser freezes on loading a large page with UniversalLanguageSelector (ULS)
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
UniversalLanguageSelector (Other open bugs)
unspecified
All All
: High normal with 2 votes (vote)
: ---
Assigned To: Niklas Laxström
: javascript
: 50245 (view as bug list)
Depends on:
Blocks: code_quality
  Show dependency treegraph
 
Reported: 2013-06-21 06:10 UTC by Ravishankar
Modified: 2013-11-02 11:52 UTC (History)
29 users (show)

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


Attachments
Screenshot on Firefox 22.0 (Win XP) (105.13 KB, image/png)
2013-07-09 20:08 UTC, Helder
Details
Runtime analysis done with Firefox 22's profiler (139.92 KB, image/png)
2013-07-10 19:43 UTC, Eduard Braun
Details
Flame chart profile (102.06 KB, image/png)
2013-07-10 20:37 UTC, Niklas Laxström
Details
Tree profile (207.15 KB, image/png)
2013-07-10 20:40 UTC, Niklas Laxström
Details

Description Ravishankar 2013-06-21 06:10:05 UTC
Hi, 

On loading web fonts in larger pages, the browser gets frozen. 

In pages like Recent changes, it is throwing an error. 

Please check 

http://upload.wikimedia.org/wikipedia/ta/f/fb/Tawiki-screenshot-13Jun2013.png

for a screenshot of the error.
Comment 1 Nemo 2013-06-21 06:23:52 UTC
This should be addressed by this commit submitted some days ago, AFAIK. https://github.com/wikimedia/jquery.uls/pull/97
Comment 2 Siebrand Mazeland 2013-06-21 07:21:19 UTC
(In reply to comment #1)
> This should be addressed by this commit submitted some days ago, AFAIK.
> https://github.com/wikimedia/jquery.uls/pull/97

Matmarex, Santhosh, can you please confirm this statement?
Comment 3 Bartosz Dziewoński 2013-06-21 08:14:03 UTC
Sadly it probably won't help (that patch only addresses performance issues on showing the main ULS window).
Comment 4 Nemo 2013-06-21 08:46:37 UTC
Ok, sorry, I may misremember a comment about that screenshot and commit.
Comment 5 Siebrand Mazeland 2013-06-25 12:03:37 UTC
I'm sorry, but I have to closed this issue as invalid. Please use http://www.mediawiki.org/wiki/How_to_report_a_bug as a guide on providing actionable reports of issues you encounter.

Detailed steps to reproduce, operating system (with version) and browser (with version) are at least needed to look into this any further.

Please do reopen if the issue persists and once the needed information is added.
Comment 6 Nemo 2013-07-04 06:51:31 UTC
(In reply to comment #5)
> Please do reopen if the issue persists and once the needed information is
> added.

Reported at <https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=562795903#Unresponsive_script>:

    A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete.

    Script: http://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2CloadingSpinner%2CmwEmbedUtil%7Cmw.MwEmbedSupport&only=scripts&skin=monobook&version=20130620T163512Z:106 

1) Windows Vista SP2
2) Intel Celeron 1.60 GHz, 1 GB RAM, 36 MB free RAM
3) Monobook and Firefox 6.0 ["If it ain't broke, I don't usually fix it. I have noticed that some of the newer versions of Firefox hog less memory, so I probably will upgrade it at some point"]
4) Reported happening 100 % times for [[Pittsburgh Steelers]], [[Barack Obama]], [[Alec Douglas-Home]].
Comment 7 Siebrand Mazeland 2013-07-04 06:54:29 UTC
Please provide details on which component is causing the delay.
Comment 8 Nemo 2013-07-04 07:16:10 UTC
(In reply to comment #7)
> Please provide details on which component is causing the delay.

Please provide instructions to be given to the user on how to provide such details.
Comment 9 Siebrand Mazeland 2013-07-04 07:43:18 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > Please provide details on which component is causing the delay.
> 
> Please provide instructions to be given to the user on how to provide such
> details.

First step would be to stop using a browser that is out of support and update to the latest release of Firefox. Then it would be useful to know if the problem is still present.
Comment 10 Nemo 2013-07-04 07:47:47 UTC
(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > Please provide details on which component is causing the delay.
> > 
> > Please provide instructions to be given to the user on how to provide such
> > details.
> 
> First step would be to stop using a browser that is out of support and update
> to the latest release of Firefox. Then it would be useful to know if the
> problem is still present.

These are not instructions to get the information you requested in comment 7, so I'm confused as regards what's needed.
Comment 11 Nemo 2013-07-04 07:59:32 UTC
Confirmed on Firefox 21.0, Windows XP SP3, Intel Atom N270, 1 GB RAM. Note that this is a borrowed machine I don't usually have access for; I'll relay to the user instructions requested in comment 8.
Comment 12 Siebrand Mazeland 2013-07-04 08:33:53 UTC
(In reply to comment #11)
> Confirmed on Firefox 21.0, Windows XP SP3, Intel Atom N270, 1 GB RAM. Note
> that
> this is a borrowed machine I don't usually have access for; I'll relay to the
> user instructions requested in comment 8.

Thanks. Use firebug (http://getfirebug.com/javascript) and profile the page load and display.
Comment 13 Nemo 2013-07-04 08:37:44 UTC
(In reply to comment #12)
> Thanks. Use firebug (http://getfirebug.com/javascript) and profile the page
> load and display.

I can't do this myself, do you know of a link to a tutorial I can point the user to? Thanks.
Comment 14 Bartosz Dziewoński 2013-07-04 08:54:02 UTC
The root cause of this is most like ULS using a *synchronous* AJAX API request on every page load (grep for "async: false").

I didn't expect to find something like that in real deployed code. It's seriously "The Daily WTF" material.

Moving back to ULS component. Siebrand, fix this and stop acting like it's not your problem.
Comment 15 Siebrand Mazeland 2013-07-04 09:10:57 UTC
(In reply to comment #14)
> The root cause of this is most like ULS using a *synchronous* AJAX API
> request on every page load (grep for "async: false").

Are you able of providing more information, Bartosz? I don't know how to look into this.
Comment 16 Bartosz Dziewoński 2013-07-04 09:16:17 UTC
(In reply to comment #15)
> Are you able of providing more information, Bartosz? I don't know how to look
> into this.

Grep the mediawiki/extensions/UniversalLanguageSelector repository "async: false". The offending file is lib/jquery.i18n.js, in particular these lines:

		jsonMessageLoader: function ( url ) {
			var that = this;
			return $.ajax( {
				url: url,
				dataType: "json",
				async: false
			// that is unfortunate
			} ).fail( function ( jqxhr, settings, exception ) {
				that.log( "Error in loading messages from " + url + " Exception: " + exception );
			} );
		},

Make it load it asynchronously. Depending on how badly the rest of the code is written, this might require just changing 'false' to 'true' or rewriting half of the library. It's a nasty issue anyway that should have been avoided from the start instead of fixed now and I'm not going to dig into it for my own sanity. Sadly you guys are paid for this and this is your duty, so you have to. Good luck.
Comment 17 Bartosz Dziewoński 2013-07-04 09:32:29 UTC
Actually, the right way to do this would be just not to send that API request and instead load whatever data you need via ResourceLoader.
Comment 19 Derk-Jan Hartman 2013-07-05 17:31:41 UTC
The user did his best (1st try) of profiling and says: "jQuery.expr.filters.hidden() is the problem"
Comment 20 kipod 2013-07-05 20:21:19 UTC
(In reply to comment #19)
> The user did his best (1st try) of profiling and says:
> "jQuery.expr.filters.hidden() is the problem"

i think this is a different issue. the report you quote pertains to a high-CPU-load issue, and this one is frozen-browser issue. (the other one is a real problem, but it's not the same as this one).

peace.
Comment 21 Gerrit Notification Bot 2013-07-08 06:55:23 UTC
Change 71990 had a related patch set uploaded by Santhosh:
jquery.i18n message store for ULS

https://gerrit.wikimedia.org/r/71990
Comment 22 Gerrit Notification Bot 2013-07-08 07:05:01 UTC
Change 71990 merged by jenkins-bot:
jquery.i18n message store for ULS

https://gerrit.wikimedia.org/r/71990
Comment 23 Siebrand Mazeland 2013-07-08 14:04:43 UTC
*** Bug 50245 has been marked as a duplicate of this bug. ***
Comment 24 kipod 2013-07-08 15:00:40 UTC
(In reply to comment #22)
> Change 71990 merged by jenkins-bot:
> jquery.i18n message store for ULS
> 
> https://gerrit.wikimedia.org/r/71990

maybe replying to a bot is plain stupid of me, but let me try:

the problem of freezing the browser is plainly and clearly related to calling ajax with "async:false". 

it is also very clear why this type of problem will be intermittent: it depends on the network and the server: if the network and server are both A-OK, the user will hardly notice any problem. 

however, if the localized messages page does not arrive to the browser promptly, "async:false" basically *tells* the browser to freeze.


since this patch does not remove the "async:false", it should not be expected to solve the issue.


(as of now, it's line 481 in jquery.i18n.js on head version in git: https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FUniversalLanguageSelector/HEAD/lib%2Fjquery.i18n.js )


peace.
Comment 25 Santhosh Thottingal 2013-07-09 03:31:21 UTC
kipod, that path of code in the library will never get executed from ULS. If you read the code again, you will see that instead of using jquery.i18n message loading mechanism, which is generic, not written specifically for MW, we have our  own message loading and saving mechanism, that always use asynchronous loading. Look for the MWMessageStore definition in the code. Thanks.
Comment 26 kipod 2013-07-09 16:38:29 UTC
(In reply to comment #25)
> kipod, that path of code in the library will never get executed from ULS. If
> you read the code again, you will see that instead of using jquery.i18n
> message
> loading mechanism, which is generic, not written specifically for MW, we have
> our  own message loading and saving mechanism, that always use asynchronous
> loading. Look for the MWMessageStore definition in the code. Thanks.

not sure i understand. this code has your signature/copyright messsage, and appears in the tree under "univerals language selector". 
what is the generic library this was imported from? 
is it used for anything other than ULS?
if it's never executed, why is it there? what's the point of keeping dead code in the tree?

is it possible to remove all the dead code from the project?
i think this will help volunteers (and non-volunteers) to identify the *real* problems a bit easier.

in any event, if this code is never executed, then we can't blame "async:false" for the lockups, so "someone" has to figure out the real cause for the lockups many users reported. 
if you think some other code change maybe solved the problem, it may be worthwhile going back to those people to find out if the problem still exists.

peace.
Comment 27 Bawolff (Brian Wolff) 2013-07-09 17:10:50 UTC
On my browser the line:

webfonts.$element.find( '*[lang], [style], [class]' ).each( function( i, element )

of jQuery.webfonts.js (about line 134). seems to be expensive.
Comment 28 SpeedyGonsales 2013-07-09 17:58:47 UTC
Firefox 22, Windows 7 & Vector, 2 GB 
Firefox 22, Linux kernel 3.5 branch & Monobook, 4 GB

http://bits.wikimedia.org/hr.wikipedia.org/load.php?debug=false&lang=hr&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2CloadingSpinner%2CmwEmbedUtil%7Cmw.MwEmbedSupport&only=scripts&skin=vector&version=20130620T163512Z:106

Vector & Windows URL of unresponsive script
Comment 30 kipod 2013-07-09 18:40:37 UTC
(In reply to comment #29)
> Firebug profiler reports 9210 calls & 20186.226ms in 
> 
> http://bits.wikimedia.org/hr.wikipedia.org/load.
> php?debug=false&lang=hr&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.
> triggerQueueCallback%2CloadingSpinner%2CmwEmbedUtil%7Cmw.
> MwEmbedSupport&only=scripts&skin=monobook&version=20130620T163512Z
> 
> Total is (22094.644ms, 152876 calls), so above is 91.36 %.

can you run the same profiling again, but with "?debug=1" added to address line?
this will allow to identify the actual file/function much better.

peace.


(In reply to comment #27)
> On my browser the line:
> 
> webfonts.$element.find( '*[lang], [style], [class]' ).each( function( i,
> element )
> 
> of jQuery.webfonts.js (about line 134). seems to be expensive.


this seems to be related to bug 50836 (i.e., performance vs. freeze).
i think if you'll dig a bit deeper you'll find that the expensive part there is calling "getCSS()". 
this can be easily improved by doing the little optimization i outlined there for the "load" function.

peace.
Comment 31 Bawolff (Brian Wolff) 2013-07-09 18:52:55 UTC
> 
> this seems to be related to bug 50836 (i.e., performance vs. freeze).
> i think if you'll dig a bit deeper you'll find that the expensive part there
> is
> calling "getCSS()". 
> this can be easily improved by doing the little optimization i outlined there
> for the "load" function.
> 
> peace.

Depending on the browser, a high cpu spike could equal browser lock up until its done doing what its doing. Are we sure these two bugs aren't the same issue?
Comment 32 SpeedyGonsales 2013-07-09 19:19:53 UTC
This time 9223 calls, 20145.512ms &debug=1 gives:

load.p...163512Z (line 6824)

if ( window.getComputedStyle ) {                    6822
curCSS = function( elem, name ) {                   6823
var ret, width, minWidth, maxWidth,                 6824
computed = window.getComputedStyle( elem, null ),   6825
style = elem.style;

-------------------------------

Seems like recursion on window.getComputedStyle().
Comment 33 Bartosz Dziewoński 2013-07-09 19:46:42 UTC
That sounds like something is calling $el.css('property') repeatedly without caching the result. So it's either yet another performance issue (fourth or fifth by my count) or an error in the measurement method.
Comment 34 Bawolff (Brian Wolff) 2013-07-09 19:50:15 UTC
(In reply to comment #33)
> That sounds like something is calling $el.css('property') repeatedly without
> caching the result. So it's either yet another performance issue (fourth or
> fifth by my count) or an error in the measurement method.

I think its the same issue that I was having
Comment 35 Helder 2013-07-09 20:08:33 UTC
Created attachment 12808 [details]
Screenshot on Firefox 22.0 (Win XP)
Comment 36 kipod 2013-07-09 20:58:48 UTC
(In reply to comment #33)
> That sounds like something is calling $el.css('property') repeatedly without
> caching the result. So it's either yet another performance issue (fourth or
> fifth by my count) or an error in the measurement method.


this actually *is* bug 50836. 
there is a little explanation there (getCSS() is called from "load", but the results are not cached, as you and Bartos noted), and an untested patch that fixes the issue.

if the people who reported the "freeze" can confirm they see high cpu usage during the time the browser is frozen, i think it would mean that you were right, and the two reports are actually duplicates. 
Either way, the profiling information definitely fits bug 50836 .


peace.
Comment 37 Strainu 2013-07-10 07:23:30 UTC
(In reply to comment #36)
> 
> if the people who reported the "freeze" can confirm they see high cpu usage
> during the time the browser is frozen, i think it would mean that you were
> right, and the two reports are actually duplicates. 
> Either way, the profiling information definitely fits bug 50836 .

I can confirm that. High CPU usage is present even without the "freeze". On a Quad Core@3GHz, Firefox does not freeze, but one of the cores is 100% busy. On a Dual Core@2.40GHz, Firefox freezes and again, one core is at 100%.
Comment 38 Bartosz Dziewoński 2013-07-10 11:24:28 UTC
Just a note that the Language Engineering team responsible for ULS will be holding an office hour later today, at 17:00 UTC on
#wikimedia-office (on Freenode): http://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg69718.html
Comment 39 Nemo 2013-07-10 16:27:25 UTC
(In reply to comment #11)
> Confirmed on Firefox 21.0, Windows XP SP3, Intel Atom N270, 1 GB RAM. 

Work for me with that machine on http://en.wikipedia.beta.wmflabs.org/wiki/Barack_Obama after https://gerrit.wikimedia.org/r/72967, no idea about CPU usage (though I watched it).
Comment 40 Nemo 2013-07-10 16:35:46 UTC
(In reply to comment #39)
> (In reply to comment #11)
> > Confirmed on Firefox 21.0, Windows XP SP3, Intel Atom N270, 1 GB RAM. 
> 
> Work for me with that machine on
> http://en.wikipedia.beta.wmflabs.org/wiki/Barack_Obama after
> https://gerrit.wikimedia.org/r/72967, no idea about CPU usage (though I
> watched
> it).

Works as in doesn't freeze; I'm no longer served the font to see the dv interwiki, I don't know if this is expected (chr font is missing for me in both cases). On Linux/AMD E350 I definitely notice the CPU usage decrease too (bug 50836).
Comment 41 Amir E. Aharoni 2013-07-10 18:52:40 UTC
(In reply to comment #40)
> (In reply to comment #39)
> > (In reply to comment #11)
> > > Confirmed on Firefox 21.0, Windows XP SP3, Intel Atom N270, 1 GB RAM. 
> > 
> > Work for me with that machine on
> > http://en.wikipedia.beta.wmflabs.org/wiki/Barack_Obama after
> > https://gerrit.wikimedia.org/r/72967, no idea about CPU usage (though I
> > watched
> > it).
> 
> Works as in doesn't freeze; I'm no longer served the font to see the dv
> interwiki, I don't know if this is expected (chr font is missing for me in
> both
> cases). On Linux/AMD E350 I definitely notice the CPU usage decrease too (bug
> 50836).

Nemo, thanks for this comment - it helped us uncover another bug, which we fixed before the deployment.

The fixes are deployed now, so the major performance problem should be mostly resolved now. Please test.
Comment 42 Eduard Braun 2013-07-10 19:43:09 UTC
Created attachment 12817 [details]
Runtime analysis done with Firefox 22's profiler

Hmmm... It's much better now - but it's still slow as hell.

See the runtime analysis I just did with Firefox 22's internal profiler on Windows 7 x64 loading [[en:Special:RecentChanges]] (using debug=yes).
Comment 43 Niklas Laxström 2013-07-10 20:37:31 UTC
Created attachment 12818 [details]
Flame chart profile
Comment 44 Niklas Laxström 2013-07-10 20:40:52 UTC
Created attachment 12819 [details]
Tree profile

In your screenshot I don't see anything that hints to ULS webfonts loading.

Here are my profiles on Chrome. You can clearly see that webfonts are in the call stack. They still do take time, but less than before the performance fix I deployed few hours ago. The time taken is split between curCSS and appendChild (adding the font-face definitions to CSS).
Comment 45 kipod 2013-07-19 15:57:53 UTC
i think this should be closed. 
did not see any report about freezing browser since the patch was deployed.
did anyone see any more report(s) about browser freezing after the patch was deployed?


peace.

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


Navigation
Links