1317032 - Scripting on website making Firefox completely unresposive

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect, P2)

Description

[Doktor Notor]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Safari/537.36

Steps to reproduce:

Browse to http://umlnotation.sparxsystems.eu/#chapter_EE843E93_9D9B_44d5_AD15_6B6F3371710C


Actual results:

Browser completely unresponsive, does not come back even after tens of minutes.


Expected results:

Render the page! The above page is no problem with Chromium-based browsers, takes ~4-10 seconds to render, depending on hardware.

Comment 1

[YF (Yang)]

The tab hang in e10s.

Comment 2

[Hani Yacoub, Desktop QA]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161104212021

I reproduced this bug on windows 7 64 bit, on version 50 branch.
On the latest nightly the browser is not completely unresponsive but it takes about 10 minutes to open completely.

Comment 3

[Hani Yacoub, Desktop QA]

I retested on the latest nightly 53.0a1 with e10s disabled and the browser is completely unresponsive.
While with e10s enabled it takes about 10 minutes to open completely.

Comment 4

[Mike Conley (:mconley) (:⚙️)]

10 minutes. That's beyond horrible. We should get a profile from this to see where we're spending our time.

Comment 5

[Mike Conley (:mconley) (:⚙️)]

With some local debugging, it looks like we're firing PluginRemoved events forever. I have no idea what that page is doing, but the PluginRemoved event handling is completely bogging down the main thread.

I'm going to tentatively move this to Core :: Plug-ins.

Comment 6

[Ben Kelly [:bkelly, not reviewing]]

We could probably fire these at the ThrottledEventQueue for the TabGroup without much web compat concern.  It would likely back up until OOM, though, unless we somehow stopped producing the events at some point.

Comment 7

[Benjamin Smedberg]

mconley, do you know if the site is actually removing plugin elements frequently, or whether some kind of iloop in our code is constantly redispatching/reentering content?

Throttling sounds like too much of a bandaid here, given that content can easily dispatch all sorts of events like this, if not this specific one.

Comment 8

[Mike Conley (:mconley) (:⚙️)]

Attachment: Source of page

Comment 9

[Mike Conley (:mconley) (:⚙️)]

(In reply to Benjamin Smedberg [:bsmedberg] from comment #7)
> mconley, do you know if the site is actually removing plugin elements
> frequently, or whether some kind of iloop in our code is constantly
> redispatching/reentering content?
> 
> Throttling sounds like too much of a bandaid here, given that content can
> easily dispatch all sorts of events like this, if not this specific one.

Inspecting the source, I'm seeing a lot of uses of <object> for non-plugin things. Example:

<div>
    <object>Description A transition is a directed relationship between a source vertex and a target vertex. It may be part of a compound transition, which takes the state machine from one state configuration to another, representing the complete response of the state machine to an occurrence of an event of ...</object>
  </div>

I have no idea if that's related, but it seems suspicious. The number of <object>'s on the page is 10027.

Comment 10

[Benjamin Smedberg]

Indeed, that will kill things. We should probably fix this such that pluginremoved events only trigger updateNotificationUI if they were a plugin. I'll try it.

Comment 11

[Benjamin Smedberg]

Attachment: Bug 1317032 - If a page uses or removes many <object> elements which are not actually plugins, loading the page goes to a crawl because we recalculate the plugin UI every time.

Review commit: https://reviewboard.mozilla.org/r/98844/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/98844/

Comment 12

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

Comment on attachment 8818917 [details]
Bug 1317032 - If a page uses or removes many <object> elements which are not actually plugins, loading the page goes to a crawl because we recalculate the plugin UI every time.

https://reviewboard.mozilla.org/r/98844/#review99132

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/2da13354fde5
If a page uses or removes many <object> elements which are not actually plugins, loading the page goes to a crawl because we recalculate the plugin UI every time. Don't do that by only dispatching a PluginRemoved event for actual plugins, not images/unknown/iframe-type <objects>, r=qdot

Comment 14

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/2da13354fde5