Resolve extension startup errors

[jonathanKingston]

Reviewer:

Description:

Fixes issue with tracker methods that check the list without knowing if the list has loaded.

Errors such as:

• TypeError: Cannot read property 'duckduckgo.com' of undefined
• tried to detect trackers before rules were loaded

This makes all tracker checks fail open which I think is essentially what we are doing currently whilst also breaking other code.

This also handles missing tab data for getArgumentsObject calls by creating a tab given the sender info. This only happens on extension startup time:

This also handles getSettings calls not returning as they've not loaded yet:

Steps to test this PR:

1. Load the extension
2. Check the extension console for these messages

Automated tests:

• Unit tests
• Integration tests

Reviewer Checklist:

• Ensure the PR solves the problem
• Review every line of code
• Ensure the PR does no harm by testing the changes thoroughly
• Get help if you're uncomfortable with any of the above!
• Determine if there are any quick wins that improve the implementation

PR Author Checklist:

• Get advice or leverage existing code
• Agree on technical approach with reviewer (if the changes are nuanced)
• Ensure that there is a testing strategy (and documented non-automated tests)
• Ensure there is a documented monitoring strategy (if necessary)
• Consider systems implications

[sammacbeth]

I'm not sure this wrapping and guarding of these functions is the correct approach. As a consumer of that API I don't know if a result is correct, or just because loading isn't finish. We should instead use a hasTrackerListLoaded on the features, e.g. in the webRequest listeners return early when the list isn't loaded yet.

[sammacbeth]

Can we write down which cases this is for? Is there a case when a content-script message comes before chrome.tabs.onUpdated fires? Or is this just for the case when the extension is loaded/reload and content-scripts trigger for existing tabs (in which case we could do chrome.tabs.query on startup)?

[jonathanKingston]

Or is this just for the case when the extension is loaded/reload and content-scripts trigger for existing tabs (in which case we could do chrome.tabs.query on startup)?

This is the case I was testing. I will check.

[sammacbeth]

Why don't we make this change upstream, or extend from Trackers in trackers.es6.js? I think there is a lot of cases where we are using trackers directly, would we have to update every one to trackerutils?

[jonathanKingston]

Right, I was trying not to modify this code given the short timeline however I think we should as you mention do it upstream and propagate it back.

[jonathanKingston]

As a consumer of that API I don't know if a result is correct, or just because loading isn't finish. We should instead use a hasTrackerListLoaded on the features

Arguably the consumer here is in control of tracking when they've pushed data in. However I'm happy to update the producer to fail gracefully and expect the consumer to check a method that they expose.

I'm going to close this as we picked another avenue for now. I'll create a new issue to track this so we can get it resolved properly.

[ghostwords]

You could also delay registering the listeners until completion of all async tasks required by the listeners.

Here is a related extension/browser startup issue, by the way: EFForg/privacybadger#1845.