[meta] Get Ghostery working with WebExtensions

RESOLVED FIXED

Status

()

Toolkit
WebExtensions: Untriaged
RESOLVED FIXED
a year ago
a year ago

People

(Reporter: billm, Unassigned)

Tracking

unspecified
Points:
---
Dependency tree / graph
Bug Flags:
blocking-webextensions +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: triaged)

(Reporter)

Description

a year ago
This is a tracking bug to implement all the APIs in order to get Ghostery working with WebExtensions. The Ghostery developers are interested (and CCed on this bug).

I'll do some testing soon and see what needs to be done here. I think it's mostly webrequest stuff.
Flags: needinfo?(wmccloskey)
(Reporter)

Comment 1

a year ago
So far it looks like we would need some webrequest and webnavigation stuff as well as options pages. I also found a bug where we're claiming to support onHistoryStateUpdated even though we don't. I'll fix that now.

I had to modify Ghostery to use chrome.tabs.onActivated instead of chrome.tabs.onActiveChanged. I also commented out setUninstallUrl.
Depends on: 1215197, 1202734, 1212684
Flags: needinfo?(wmccloskey)
(Reporter)

Updated

a year ago
Flags: blocking-webextensions?

Updated

a year ago
Flags: blocking-webextensions? → blocking-webextensions+

Comment 2

a year ago
Hey Bill, just checking on the progress of this ticket. Is there anything we can do to help? This is blocking our ability to integrate the Ghostery extension with e10s.
Flags: needinfo?(wmccloskey)
(Reporter)

Comment 3

a year ago
Thanks for checking in Chris. Switching the Chrome version of Ghostery to chrome.tabs.onActivated, as in comment 1, would be a great first start. Also, if you guys could detect when setUninstallUrl is unavailable and avoid calling it, that might help (although I'm hoping we'll have it soon).

The main blocker here is bug 1202734. Giorgio is working on that right now I think.
Depends on: 1156826
Flags: needinfo?(wmccloskey)
(Reporter)

Comment 4

a year ago
We'll also need to figure out what to do about the options UI. Work for that hasn't really been scheduled, so it will take longer. If Ghostery had a way of opening the options from its pop-up, that would be a good workaround I think. (Maybe it does already?)
(In reply to Bill McCloskey (:billm) from comment #3)

> The main blocker here is bug 1202734. Giorgio is working on that right now I
> think.

Yes I am :)

Comment 6

a year ago
Hey Bill, thanks for the quick reply. I can get a build put together with the tabs.onActivated fix. I'll also look into fixing setUninstallUrl, but at this point we would be fine going to production without it.  It's a low priority feature. 

The options UI shouldn't be a blocker for us.  We have a new Ghostery version in the works that uses an external ghostery.com page to handle user settings. Thanks again for the update.
(Reporter)

Comment 7

a year ago
Thanks!

(In reply to Christopher Tino from comment #6)
> I'll also look into fixing setUninstallUrl, but at
> this point we would be fine going to production without it.  It's a low
> priority feature. 

Yeah, mostly we just need to make sure it doesn't get called if it's not available. Otherwise you'll get an exception and execution will stop, which could break other things. Something like this should work:

if (chrome.runtime.setUninstallUrl) {
  chrome.runtime.setUninstallUrl("url");
}

> The options UI shouldn't be a blocker for us.  We have a new Ghostery
> version in the works that uses an external ghostery.com page to handle user
> settings. Thanks again for the update.

Sounds great!

Updated

a year ago
Whiteboard: triaged
Christopher let me know over email that they have a new version that doesn't need the options_page (or options_ui), so I'm removing that bug from the dependencies.
No longer depends on: 1212684
In case you did not notice, you've got requestId support now :)

Comment 10

a year ago
Thanks Giorgio.  We'll put a new build together and test it this week.

Comment 11

a year ago
We ported over Ghostery v6 from Chrome today and, after a few minor tweaks, it seems to be working pretty well.  There was a small issue with webRequest.onErrorOccurred (see Bug 1252596). We'll keep testing but at first glance this seems solid. Thanks everyone!

Updated

a year ago
Depends on: 1252596
All dependencies are closed, so based on comment 11, closing this tracker. Please re-open or file new bugs for new issues.

Updated

a year ago
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.