If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Adblock Plus broken in e10s since Nightly 20140719

VERIFIED FIXED in Firefox 36

Status

()

Firefox
Extension Compatibility
VERIFIED FIXED
3 years ago
3 years ago

People

(Reporter: Grant, Assigned: billm)

Tracking

(Blocks: 1 bug, {regression})

33 Branch
Firefox 34
x86
Windows 8.1
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

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

Details

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
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
(Reporter)

Comment 1

3 years ago
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

Comment 2

3 years ago
> 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: 905436
status-firefox32: --- → unaffected
status-firefox33: --- → affected
status-firefox34: --- → ?
tracking-e10s: --- → ?
Flags: needinfo?(wmccloskey)
Keywords: regression

Updated

3 years ago
Blocks: 467520
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1041071
(Reporter)

Comment 5

3 years ago
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?
tracking-e10s: ? → +
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 → ---
(Assignee)

Comment 7

3 years ago
No need. This is almost certainly bug 1007982.
Flags: needinfo?(wmccloskey)
Flags: needinfo?(tenisthenewnine)
(Assignee)

Updated

3 years ago
Assignee: nobody → wmccloskey
(Assignee)

Comment 8

3 years ago
Created attachment 8462825 [details] [diff] [review]
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.
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+
(Assignee)

Comment 10

3 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/b05b6fe7524e
https://hg.mozilla.org/mozilla-central/rev/b05b6fe7524e
Status: REOPENED → RESOLVED
Last Resolved: 3 years ago3 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
status-firefox36: --- → verified
You need to log in before you can comment on or make changes to this bug.