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

Status: RESOLVED FIXED

(Firefox :: Extension Compatibility, defect)

Description

[Chris Peterson [:cpeterson]]

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.

Comment 1

[Wladimir Palant]

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.

Comment 2

[Chris Peterson [:cpeterson]]

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

Comment 3

[Wladimir Palant]

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.

Comment 4

[Brad Lassey [:blassey] (use needinfo?)]

Bill, seems like your addon compartments could come into play here

Comment 5

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

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) { ... });

Comment 6

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

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?

Comment 7

[Chris Peterson [: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

Comment 8

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

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

Comment 9

[Chris Peterson [:cpeterson]]

Attachment: 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".

Comment 10

[Wladimir Palant]

Same here, I can also still reproduce this issue on OS X - same nightly. Could it be OS-dependent?

Comment 11

[Cork]

I can reproduce in linux and win2k8r2 2014-07-15 nightly

Comment 12

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

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?

Comment 13

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

Also, you'll need to test with browser.tabs.remote.autostart. The shims don't work otherwise.

Comment 14

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

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

Comment 15

[Chris Peterson [:cpeterson]]

WFM in Nightly 2014-07-16 on OS X when I use browser.tabs.remote.autostart. \o/

Comment 17

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

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.

Comment 18

[Elbart]

The bug seems to be back, as I can reproduce it in Nightly 20150402 and ABP 2.6.9.

Comment 19

[Elbart]

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

Comment 20

[Cork]

(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.

Comment 21

[Elbart]

Filed bug 1151335 and moving the ni? over.