Adblock Plus broken in e10s since Nightly 20140719

VERIFIED FIXED in Firefox 36



5 years ago
5 years ago


(Reporter: tenisthenewnine, Assigned: billm)



33 Branch
Firefox 34
Windows 8.1
Dependency tree / graph

Firefox Tracking Flags

(e10s+, firefox32 unaffected, firefox33 affected, firefox34 ?, firefox36 verified)



(1 attachment)

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 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?

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

Component: Untriaged → Extension Compatibility
> I have posted a writeup about this, with some screenshots here:
> php?f=23&t=2779793&p=13675751#p13675751
> Thanks

Ever confirmed: true
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:
Blocks: e10s-addons
tracking-e10s: --- → ?
Flags: needinfo?(wmccloskey)
Keywords: regression
Blocks: abp
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1041071
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?
Summary: Adblock Plus broken in e10's since 20140719 → Adblock Plus broken in e10s since Nightly 20140719
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:

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
Flags: needinfo?(tenisthenewnine)
Resolution: DUPLICATE → ---
No need. This is almost certainly bug 1007982.
Flags: needinfo?(wmccloskey)
Flags: needinfo?(tenisthenewnine)
Assignee: nobody → wmccloskey
Posted patch about-fixSplinter Review
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.
Attachment #8462825 - Flags: review?(mconley)
Comment on attachment 8462825 [details] [diff] [review]

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[";1"]
> +               .getService(Ci.nsISyncMessageSender);
> +    var rval = cpmm.sendRpcMessage("Addons:AboutProtocol:OpenChannel", {

let, not var
Attachment #8462825 - Flags: review?(mconley) → review+
Closed: 5 years ago5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 34
QA Whiteboard: [qa+]
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).
You need to log in before you can comment on or make changes to this bug.