1041334 - Adblock Plus broken in e10s since Nightly 20140719

Status: VERIFIED FIXED

(Firefox :: Extension Compatibility, defect)

Description

[Grant]

Hi all

1. Install ABP, and add a filter list on Nightly
2. change about:config to enable remote tabs, and restart
3. Load a page with e10s enabled (I used anandtech.com) and also load the same page with a non-e10's window and compare them

It seems ABP is only partially blocking content, and none of the element hiding rules are working.

This worked fine in 20140718 build - what's changed?

Thanks

Comment 1

[Grant]

I have posted a writeup about this, with some screenshots here:

http://forums.mozillazine.org/viewtopic.php?f=23&t=2779793&p=13675751#p13675751

Thanks

Comment 2

[gabe]

> I have posted a writeup about this, with some screenshots here:
> 
> http://forums.mozillazine.org/viewtopic.
> php?f=23&t=2779793&p=13675751#p13675751
> 
> Thanks

confirmed

Comment 3

[Chris Peterson [:cpeterson]]

Bill: could this AdBlock Plus problem be a regression from bug 950745 ("Flag when we're processing urgent messages and disallow certain activities")? It's one of a few e10s-related changesets in the pushlog between Nightly 33 build 2014-07-18 and 2014-07-19:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=99f694d1b50c&tochange=35f3fa435d2c

Comment 5

[Grant]

I'm not sure this is a duplicate of that bug, as this has only happened since that build yet EHH hasn't worked in ever?

Comment 6

[Chris Peterson [:cpeterson]]

Reopening based on Grant's comment 5.

Grant: If you have time, do you mind using the "mozregression" Python script to find the code change that broke AdBlock Plus?

Instructions for install and running mozregression: http://mozilla.github.io/mozregression

If you are sure Nightly build 20140718 was a good build, then you use the following command line parameters to narrow the date range that mozregression will test. I am assuming Nightly build 20140720 was a bad build because that was the date when you reported this bug. :)

mozregression --good=2014-07-18 --bad=2014-07-20

Comment 7

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

No need. This is almost certainly bug 1007982.

Comment 8

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

Attachment: about-fix

It turns out that the patch in bug 1007982 took us from blocking everything to blocking nothing. If you look at Adblock's HitRegistrationChannel open method, it calls Utils.getRequestWindow(this). That code uses the notificationCallbacks on the channel to find the associatedWindow. The patch in bug 1007982 left notificationCallbacks null, and so we always got a null window back from getRequestWindow, which causes Adblock to always block.

Gecko doesn't set notificationCallbacks on a channel until right before opening it, so I had to shift some code around so that we can pass a CPOW for notificationCallbacks up to the parent.

Comment 9

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

Comment on attachment 8462825 [details] [diff] [review]
about-fix

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

Code looks good, and works as advertised. I also made sure this didn't regress bug 1007982.

Just one nit.

::: toolkit/components/addoncompat/RemoteAddonsChild.jsm
@@ +178,5 @@
>    asyncOpen: function(listener, context) {
> +    // Ask the parent to synchronously read all the data from the channel.
> +    let cpmm = Cc["@mozilla.org/childprocessmessagemanager;1"]
> +               .getService(Ci.nsISyncMessageSender);
> +    var rval = cpmm.sendRpcMessage("Addons:AboutProtocol:OpenChannel", {

let, not var

Comment 10

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

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

Comment 11

[Carsten Book [:Tomcat]]

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

Comment 12

[Vasilica Tamas, QA [:vtamas]]

I was able to reproduce this bug on Nightly 33.0a1 (2014-07-20), using Windows 8.1 x32.

Verified fixed on Windows 8.1 x32 using latest Nightly 36.0a1 (2014-11-07).