1101189 - (e10s-ghostery) [e10s] Ghostery add-on tracking meta bug for e10s

Status: RESOLVED WORKSFORME

(Firefox :: Extension Compatibility, defect, P3)

Comment 1

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

Ghostery appears to be a Jetpack addon, but it uses nsIContentPolicy. Its content policy examines the document when deciding whether to block, so it's not possible to use nsISimpleContentPolicy.

Comment 2

[Daniel Veditz [:dveditz]]

Ghostery regularly modifies documents as well, adding placeholder widgets for functionality they block for privacy reasons but which the user may wish to reactivate on a case-by-case basis (e.g. Disquus comments, share buttons, etc).

Comment 3

[Robson Sobral]

I don't know if this is a valuable information, but...

Is it strange that the add-on works on the first window, but not on new ones?

Two windows. The first can open resource://firefox-at-ghostery-dot-com/ghostery/data/options.html, but the second doesn't.

Comment 4

[Giorgio Maone [:ma1]]

[e10s tracking info]

Assignee: Giorgio Maone

Link to add-on: https://addons.mozilla.org/firefox/addon/ghostery/

Contact info for add-on: https://www.ghostery.com/en/about-us/contact-us/

Add-on ID: [e-mail]

How well does it work?: Broken (some of the UI works, but the core blocking feature doesn't)

Steps to reproduce working features:
* Follow the tutorial which starts automatically when you first click Ghostery's "little blue ghost" toolbar icon, to familiarize with concepts and UI
* Visit any page including trackers, e.g. https://www.surveymonkey.com/r/FWSW82F and play with the buttons (status sticks)


Steps to reproduce broken features: 
* Just install it and notice the broken walkthrough, or click the Options button behind the Configuration icon and notice the empty page (see bug 1187065)
* Try to block anything, then reload observing the requests supposed to be blocked being instead logged with their successful response in the Net panel of the Web Console (ctrl+K)

Any obvious performance problems? N/A

SDK-based: Yes, with a nsIContentPolicy implementation, though, which is the piece most likely broken

Chromium version: https://chrome.google.com/webstore/detail/ghostery/mlomiejdfkolichcflejclcbmpeaniij?hl=en - almost identical to the Firefox version

Comment 5

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

Let's see how well the chrome version works with WebExtensions.

Comment 6

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

Just looking at the APIs it uses, I think we're pretty close to being able to get Ghostery for Chrome working. Here's what I see that we don't implement:

chrome.windows.WINDOW_ID_CURRENT
chrome.webRequest.onErrorOccurred.addListener
chrome.webRequest.onBeforeRedirect.addListener
chrome.tabs.onActiveChanged.addListener
chrome.runtime.getPlatformInfo

The only one that might be difficult is onBeforeRedirect.

Comment 7

[Giorgio Maone [:ma1]]

(In reply to Bill McCloskey (:billm) from comment #6)

> The only one that might be difficult is onBeforeRedirect.

This is one NoScript would certainly need as well.

As far as I know you just need to implement nsIChannelEventSink in a component and register it under the "net-channel-event-sinks" category in the CategoryManager.

Is there any e10s-specific pitfall in that?

Comment 8

[Andy McKay]

(In reply to Bill McCloskey (:billm) from comment #6)
> Just looking at the APIs it uses, I think we're pretty close to being able
> to get Ghostery for Chrome working. Here's what I see that we don't
> implement:
> 
> chrome.windows.WINDOW_ID_CURRENT

It looks like WINDOW_ID_CURRENT exists here: https://dxr.mozilla.org/mozilla-central/source/browser/components/extensions/ext-windows.js#14, is that line insufficient, should we file a bug on that?

Comment 9

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

I think that was fixed in bug 1202479.

Comment 10

[Karl Dubost💡 :karlcow]

Contacted the sales team of Ghostery waiting for their answers.

Comment 11

[Christopher Tino]

(In reply to Karl Dubost :karlcow from comment #10)
> Contacted the sales team of Ghostery waiting for their answers.

Hey Karl, I'm a Lead Engineer at Ghostery. You can send any questions directly to me. 

We're working on getting the extension ported over to e10s via WebExtensions. It looks like webRequest is the big sticking point right now, plus a few other items listed above. See bug 1235639.

Comment 12

[Karl Dubost💡 :karlcow]

Back from a 2 weeks away.

Thanks a lot Christopher.

Comment 13

[Christopher Tino]

An e10s compatible build (v7.0.0beta1) is now available in our development channel here:

https://addons.mozilla.org/en-US/firefox/addon/ghostery/versions/?page=1#version-7.0.0beta1

We'll be pushing to GA early next week.

Comment 14

[Michelle Funches - QA]

QA Update: I test Ghostery 7.0.1.4 on Aurora Channel with e10s enabled and disabled. Working without error.
Version 	51.0a2
Build ID 	20160928004008
User Agent 	Mozilla/5.0 (X11; Linux i686; rv:51.0) Gecko/20100101 Firefox/51.0
"ni" me if additional info is needed.

Comment 15

[:shell escalante]

great news - thank Michelle and all the folks at Ghostery!  I'll leave the tracking bug in case any bugs are reported later, since it's a popular add-on.  Also quick way to keep track of the webRequest portions that are needed for this add-on.  marked down to P3 - so it's just tracking.

Comment 16

[u473386]

Another Ghostery problem, which may or may not be related.

https://bugzilla.mozilla.org/show_bug.cgi?id=1322407

Comment 17

[Andy McKay]

I don't think this bug is useful anymore, it's been out for a few months. In the interest of cleaning up old bugs I'm going to recommend closing this. If any WebExtensions bugs come up for Ghostery, lets file them in WebExtensions: Compatability as appropriate.