Page MenuHomePhabricator

Large numbers of instances on a page cause browsers to hang or crash
Closed, ResolvedPublic

Description

On enwiki, the page [[en:Portal:Featured sounds]] embeds 380 media files. Something within TimedMediaHandler causes my browser on my laptop (Firefox 16.0.2, Linux) to grind (100% CPU, unresponsive) for about 10 minutes at around the time the DOMReady or onLoad event fires, apparently while generating the UI for all those embeds. Others on IRC reported similar experiences or outright crashes in Firefox and Chrome. In further testing, a page with 90 embeds seemed to be handled fine for me, and a page with 180 ground for about 15 seconds.

If this can't be fixed directly, perhaps TMH can process the embeds on the page in batches (waiting for one batch to complete before the next runs) or just refuse to process over a certain number of embeds in a page.


Version: unspecified
Severity: normal

Details

Reference
bz42071

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 1:02 AM
bzimport set Reference to bz42071.
Anomie created this task.Nov 13 2012, 5:33 PM

mdale wrote:

Some profiling indicates the loading animation for so many simultaneous rewriting is causing issues.

I have set the the players to rewrite one at a time
https://gerrit.wikimedia.org/r/33210

Tested on a page with 600 players, no crash or lockup, but takes some time to rewrite all the players.

Further down the road we should better handle this with something like thumbembed ( for audio players ) Where we can embed hundreds of players at a cost of < 1ms or so each ( we also use this on the gallery pages for videos )
http://html5video.org/kaltura-player/docs/Embeding/thumb

Patch doesn't seem to make a whole lot of difference here; it takes somewhat less time, but still grinds for a long time.

Also, I note that the new "checkSetDone" function is called 16290 times on my test page with 180 embeds. Something is not right there; I wonder if it's somehow processing the first one or two individually, then the multiple callbacks hit and it gets the thundering herd again.

mdale wrote:

could you try it again ( patch set 2 ) ? It does appear as if there was some call stacking because of jquery event scope issues.

There we go, now it works right!

BTW, this was discussed in the MediaWiki Core Team meeting today, and it appears that it only affects audio files and not video for some reason. That may go along with the thumbembed thing you mentioned in comment 1.

mdale wrote:

We should get this deployed, we are getting duplicate reports i.e: 24988

jgerber wrote:

https://gerrit.wikimedia.org/r/#/c/33210/ is not merged yet,
can you look the comments?

  • Bug 42541 has been marked as a duplicate of this bug. ***
Gilles triaged this task as Unbreak Now! priority.Dec 4 2014, 10:10 AM
Gilles moved this task from Untriaged to Done on the Multimedia board.
Gilles lowered the priority of this task from Unbreak Now! to Needs Triage.Dec 4 2014, 11:21 AM