Closed Bug 1041334 Opened 10 years ago Closed 10 years ago

Adblock Plus broken in e10s since Nightly 20140719

Categories

(Firefox :: Extension Compatibility, defect)

33 Branch
x86
Windows 8.1
defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 34
Tracking Status
e10s + ---
firefox32 --- unaffected
firefox33 --- affected
firefox34 --- ?
firefox36 --- verified

People

(Reporter: tenisthenewnine, Assigned: billm)

References

Details

(Keywords: regression)

Attachments

(1 file)

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
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
Component: Untriaged → Extension Compatibility
> 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
Status: UNCONFIRMED → NEW
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:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=99f694d1b50c&tochange=35f3fa435d2c
Blocks: e10s-addons
tracking-e10s: --- → ?
Flags: needinfo?(wmccloskey)
Keywords: regression
Blocks: abp
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
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: 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
Status: RESOLVED → REOPENED
Flags: needinfo?(tenisthenewnine)
Resolution: DUPLICATE → ---
No need. This is almost certainly bug 1007982.
Flags: needinfo?(wmccloskey)
Flags: needinfo?(tenisthenewnine)
Assignee: nobody → wmccloskey
Attached 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]
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
Attachment #8462825 - Flags: review?(mconley) → review+
https://hg.mozilla.org/mozilla-central/rev/b05b6fe7524e
Status: REOPENED → RESOLVED
Closed: 10 years ago10 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).
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: