1171173 - After start, Disabling/Enabling uBlock considerably lowers page load times with E10s

Status: RESOLVED FIXED

(Firefox :: Untriaged, defect)

Description

[Grant]

As reported here:
https://github.com/gorhill/uBlock/issues/214



   1. With Nightly 41's profile manager ("firefox -p"), create a new profile, install uBlock.
   2. Disable E10s, restart browser. Load "http://numion.com/stopwatch" and measure "http://spiegel.de" a few times. Note page load times.
   3. Enable E10s, restart browser. Redo the test a few times. Note that load times have gone up measurably.
   4. Open Firefox' Add-ons-Manager, disable and immediately re-enable uBlock. Redo tests. Page load times are now lower again, about on non-E10s level, but only until next browser restart, after which another disable/enable-sequence is needed to bring load times down again.

The addon developers commented on it and said:

"I am still investigating. It has something to do with browser launch only, issue disappears if manually enabling the addon after startup, or if disabling/enabling like you found out. All is the same code in both case, so I suspect there is some quirks with e10s API at launch time.

Edit: For example, if I disable uBlock, quit Nightly, launch Nightly and click as fast as possible to enable uBlock, all is fine. It's as if if uBlock is enabled, Nightly will do something bad to uBlock at launch."

Cheers

Comment 1

[u287251]

To summarize, repro steps:

Extension: https://addons.mozilla.org/en-US/firefox/addon/ublock-origin/
Nightly 41.0a1
Linux Mint 17

1. Install uBlock in Nightly (e10s enabled)
2. Quit Nightly
3. Launch Nightly
4. Open browser console
5. Load a web page, say `https://www.reddit.com/`
6. great amount of warnings: "Sending message that cannot be cloned. Are you trying to send an XPCOM object?"
7. This happens systematically at every launch

With the following steps, this does not happen:

1. Install uBlock in Nightly (e10s enabled)
2. Disable uBlock
3. Quit Nightly
4. Launch Nightly
5. Open browser console
6. Load a web page, say `https://www.reddit.com/`
7. No "Sending message that cannot be cloned. Are you trying to send an XPCOM object?" warning

For the pathological case, when I trace into the code, I see that that for some reasons the standard objects in the sandbox are not in a proper state:

1. Date object doesn't have a now() static method.
2. Math object doesn't have a random() static method.
3. String object does not have a charFromCode() static method.
4. And so on.

Just disabling/enabling uBlock solves this, or launching Nightly with uBlock disable and enabling after launch.

Comment 2

[u287251]

Correction with second set of steps: I forgot a step:

4a: Enable uBlock

Comment 3

[Alice0775 White]

Confirmed

Comment 4

[Alice0775 White]

Regression window of the slowness
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=6a160892b400&tochange=83147bd55260

Via local build
Last Good: 6a160892b400
First Bad: 5bfcda09ea13
Triggered by: 	5bfcda09ea13	Bill McCloskey — Bug 1099416 - [e10s] Make sure add-on shims are always enabled (r=ally)

Comment 5

[Grant]

Any news on this one?

Comment 6

[Alice0775 White]

( FYI, The "Sending message..." wa added by Bug 1139718 )

Comment 7

[Trevor Rowbotham [:rowbot]]

Bug 1156065 fixed some of the "Sending message that cannot be cloned. Are you trying to send an XPCOM object?" message spam.  The fix in that bug may provide some clues for fixing this one.

Comment 8

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Attachment: patch

It looks like the multiprocessCompatible flag is pretty severely broken. I think I made a mistake in rebasing when I landed it.

Anyway, the fix is pretty simple. We just need to pass it through createAddonDetails. I tried to write a test for this and I can't figure out how to do it. The problem seems to present only if the add-on was already installed when Firefox started up. I'm guessing there's a way to simulate that but I don't know how.

Felipe, if you're not the right person to review this, can you find someone? Mossop is on a three week vacation and Unfocused is marked as UNAVAILABLE in bugzilla. Irving apparently no longer works on Firefox.

One option would be to land the fix soon and then wait for Mossop to review the test when he gets back.

Comment 9

[:Felipe Gomes (needinfo for replies!)]

Comment on attachment 8629156 [details] [diff] [review]
patch

Review of attachment 8629156 [details] [diff] [review]:
-----------------------------------------------------------------

I think I'm fine with my review here, you can land it all now. Dave can take a look at the test later if he wants but I doubt he'd oppose landing this now.

Comment 11

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/be7428a919f5

Comment 12

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/be7428a919f5

Comment 14

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Comment on attachment 8629156 [details] [diff] [review]
patch

This would be nice to have or Aurora users. It fixes some e10s addon problems.

Approval Request Comment
[Feature/regressing bug #]: none
[User impact if declined]: broken add-ons (uBlock in particular)
[Describe test coverage new/current, TreeHerder]: been on m-c for a while
[Risks and why]: pretty low; won't have any effect once we go to beta.
[String/UUID change made/needed]: none

Comment 16

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8629156 [details] [diff] [review]
patch

Approving as this has been on m-c for a few days so seems stable for uplift to Aurora.

Comment 17

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/e0afc144892b