Closed Bug 1007978 Opened 6 years ago Closed 5 years ago

[e10s] Firefox does not handle Adblock Plus's adb: URL scheme in e10s window

Categories

(Firefox :: Extension Compatibility, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
Firefox 33
Tracking Status
e10s + ---
firefox32 --- affected
firefox33 --- fixed

People

(Reporter: cpeterson, Assigned: mconley)

References

Details

Attachments

(1 file)

STR:
1. Install Adblock Plus
2. Open a new e10s window.
3. Load https://easylist.adblockplus.org/en/
4. Click any of the "Add to Adblock Plus" abp: links to install a block list.

RESULT:
Nothing happens.

In a non-e10s window, clicking an "Add to Adblock Plus" abp: link opens an "Add Adblock Plus filter subscription" popup window.
For reference: Adblock Plus handles these links by adding a capturing event handler for the "click" event to the tabbrowser element. Normally this allows intercepting the clicks even before the webpage sees them.
(In reply to Wladimir Palant from comment #1)
> For reference: Adblock Plus handles these links by adding a capturing event
> handler for the "click" event to the tabbrowser element. Normally this
> allows intercepting the clicks even before the webpage sees them.

Wladimir: so Adblock Plus is not registering a protocol handler for "adb:" protocol? Can Adblock Plus run a content script to listen for the the click events in the content process?
No, registered protocols are detectable and can also be triggered by the webpage so Adblock Plus intercepts clicks (trusted events only) instead. This can also be done with content scripts of course, only issue being that the click cannot be captured above the document root then and will be visible to the webpage.
Bill, seems like your addon compartments could come into play here
Flags: needinfo?(wmccloskey)
Yes, the shims for add-ons should be able to handle this case.

> No, registered protocols are detectable and can also be triggered by the webpage so Adblock
> Plus intercepts clicks (trusted events only) instead. This can also be done with content
> scripts of course, only issue being that the click cannot be captured above the document root
> then and will be visible to the webpage.

The content script itself is an event target that is above the content document, so you should be able to register the listener there. The code just looks like this:

content.js:
addEventListener("click", function(e) { ... });
Flags: needinfo?(wmccloskey)
Assignee: nobody → mconley
No longer blocks: e10s-addons
I can no longer reproduce this bug with AdBlock Plus 2.6.3, on Nightly (July 15, 2014). The subscription dialog comes up just fine for me.

A quick debug session shows that the EventTarget interpose code is getting hit here, which is forwarding the call to the parent process.

So I think we're all good here, now.

Can you confirm, Chris?
Flags: needinfo?(cpeterson)
I can still reproduce a variant of this bug using Nightly 2014-07-15 and AdBlock Plus 2.6.3. When I click on the "Add EasyList to Adblock Plus" link, the adblockplus.org page is replaced by the following URI and a "The address wasn't understood" error message:

abp:subscribe?location=https://easylist-downloads.adblockplus.org/easylist.txt&title=EasyList
Status: NEW → ASSIGNED
Flags: needinfo?(cpeterson)
(In reply to Chris Peterson (:cpeterson) from comment #7)
> I can still reproduce a variant of this bug using Nightly 2014-07-15 and
> AdBlock Plus 2.6.3. When I click on the "Add EasyList to Adblock Plus" link,
> the adblockplus.org page is replaced by the following URI and a "The address
> wasn't understood" error message:
> 
> abp:subscribe?location=https://easylist-downloads.adblockplus.org/easylist.
> txt&title=EasyList

Hm... I'm not getting that when I click on that link. Can you reproduce that behaviour using a new profile?
Flags: needinfo?(cpeterson)
Attached image Screenshot.jpg
I can reproduce the "address wasn't understood" error using a new profile in an e10s window or with browser.tabs.remote.autostart=true. The attached screenshot shows what happens after I click "Add EasyList to Adblock Plus".
Flags: needinfo?(cpeterson)
Same here, I can also still reproduce this issue on OS X - same nightly. Could it be OS-dependent?
I can reproduce in linux and win2k8r2 2014-07-15 nightly
So, I reproduced this issue on my Windows VM, but after an upgrade to last night's Nightly (2014-07-16), it seems to be working properly again.

Perhaps I was mistaken about which version I was using in comment 6.

Is the issue still reproducible with the more recent Nightly?
Flags: needinfo?(cpeterson)
Also, you'll need to test with browser.tabs.remote.autostart. The shims don't work otherwise.
(In reply to Bill McCloskey (:billm) from comment #13)
> Also, you'll need to test with browser.tabs.remote.autostart. The shims
> don't work otherwise.

Ah, that indeed seems to make the difference. Disabling autostart causes the error page to come up.

I wasn't aware of this restriction on the shims - from what I remember, nothing in the patches suggested it. Do they break something if autostart is false?
Flags: needinfo?(wmccloskey)
WFM in Nightly 2014-07-16 on OS X when I use browser.tabs.remote.autostart. \o/
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Flags: needinfo?(cpeterson)
Resolution: --- → WORKSFORME
Resolution: WORKSFORME → FIXED
The shims don't break anything that I know if. However, if we want them to work in "New e10s window", then we would have to enable them for all add-ons and for all nightly users. The shims definitely cause a performance hit, and they probably have some bugs. I'd like them to let them stabilize for a while before enabling them for all nightly users.
Flags: needinfo?(wmccloskey)
Target Milestone: --- → Firefox 33
The bug seems to be back, as I can reproduce it in Nightly 20150402 and ABP 2.6.9.
Using the first "Add List"-link on http://www.fanboy.co.nz/

Regression-range:
Last good revision: 6bfc0e1c4b29 (2015-01-29)
First bad revision: 29b05d283b00 (2015-01-30)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6bfc0e1c4b29&tochange=29b05d283b00

Last good revision: 7e34c1037f5e
First bad revision: 5969eb0fe8b5
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=7e34c1037f5e&tochange=5969eb0fe8b5

Maybe Bug 1126018 - [e10s] Miscellaneous additions to add-on shims
Flags: needinfo?(wmccloskey)
(In reply to Elbart from comment #18)
> The bug seems to be back, as I can reproduce it in Nightly 20150402 and ABP
> 2.6.9.

File a new bug. This has already hit release, so you are seeing a separate issue.
Filed bug 1151335 and moving the ni? over.
Flags: needinfo?(wmccloskey)
You need to log in before you can comment on or make changes to this bug.