Chris Peterson [:cpeterson] Reporter
	Description • 10 years ago

      No description provided.

	Bill McCloskey [inactive unless it's an emergency] (:billm)
	Comment 1 • 9 years ago

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.

	Daniel Veditz [:dveditz]
	Comment 2 • 9 years ago

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

	Robson Sobral
	Comment 3 • 9 years ago

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.

	Giorgio Maone [:ma1]
	Comment 4 • 9 years ago

[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: firefox@ghostery.com

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

	Bill McCloskey [inactive unless it's an emergency] (:billm)
	Comment 5 • 9 years ago

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

	Bill McCloskey [inactive unless it's an emergency] (:billm)
	Comment 6 • 9 years ago

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.

	Giorgio Maone [:ma1]
	Comment 7 • 9 years ago

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

	Andy McKay
	Comment 8 • 9 years ago

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

	Bill McCloskey [inactive unless it's an emergency] (:billm)
	Comment 9 • 9 years ago

I think that was fixed in bug 1202479.

	Karl Dubost💡 :karlcow
	Comment 10 • 9 years ago
contact email

Contacted the sales team of Ghostery waiting for their answers.

	Christopher Tino
	Comment 11 • 8 years ago

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

	Karl Dubost💡 :karlcow
	Comment 12 • 8 years ago

Back from a 2 weeks away.

Thanks a lot Christopher.

	Christopher Tino
	Comment 13 • 8 years ago

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.

	Michelle Funches - QA
	Comment 14 • 8 years ago

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.

	:shell escalante
	Comment 15 • 8 years ago

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.

	u473386
	Comment 16 • 8 years ago

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

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

	Andy McKay
	Comment 17 • 7 years ago

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.