This ignores failures to get expiration data from favicon requests. It also adds
some safety to the rest of onStopRequest wrapping it in a try...catch block to
catch any unexpected errors and correctly reject the waiting promise.
Differential Revision: https://phabricator.services.mozilla.com/D1938
Summary:
This moves the load of favicons into the content process. We use the same logic
for finding favicons (based on waiting until none have shown up for a short
time) but then load the favicon and convert it to a data uri which we then
dispatch to the parent process. Along the way this fixes asssociating the load
with the tab for WebExtension and devtools, fixes CSP usage for the load, fixes
expiry detection of the favicon and stops us from loading the same resource
twice.
This change also merges the prefs browser.chrome.site_icons and
browser.chrome.favicons leaving just the former controlling favicon loading. It
adds the pref browser.chrome.guess_favicon to allow disabling guessing where
a favicon might be located for a site (at <hostname>/favicon.ico). This is
mainly to allow disabling this in tests where those additional yet automatic
requests are uninteresting for the test.
There are multiple clean-ups that can follow this but this is a first step along
that path.
MozReview-Commit-ID: E0Cs59UnxaF
Reviewers: mak
Tags: #secure-revision
Bug #: 1453751
Differential Revision: https://phabricator.services.mozilla.com/D1672
Differential Revision: https://phabricator.services.mozilla.com/D1673
Differential Revision: https://phabricator.services.mozilla.com/D1674
Differential Revision: https://phabricator.services.mozilla.com/D1850
Differential Revision: https://phabricator.services.mozilla.com/D1869
The in-tree version of View MathML Source appears to have low usage, so it seems
reasonable to remove. A similar feature is available as an add-on.
In recent months, the in-tree version has actually been broken, which wasn't
noticed for quite a while. This adds further evidence for removal given the
lack of maintenance and interest in this feature.
Differential Revision: https://phabricator.services.mozilla.com/D1830
Consuming the new 'page-visited' notification was fairly trivial,
since it was already brought over to onVisits. There's not much to
say about this other than that I'm a little bit uncertain about
all the hoops we have to jump through to get a JSContext and
GlobalObject from History.cpp (which is discussed in the earlier
commit in the series).
MozReview-Commit-ID: LHaBWSylyLI
At some point, the matching call to reporter.uninit got removed from this test.
The result is that the reporter still exists and is still collecting errors
during the rest of the tasks in the file. In most tasks, this isn't an issue
since we use reporter.handleMessage to test message handling at a per-reporter
level.
But the telemetry measures are shared between multiple reporters, thus they are
susceptible to interference from other running reporter instances.
The error that is being logged when this test fails is from the test add-on
created in testAddonIDMangle. My best guess is that the error logged by the
add-on is being processed during an idle moment in another task, since we
schedule processing to be delayed until the browser is idle. It seems this
scheduling is pretty consistent on certain Linux platforms.
Differential Revision: https://phabricator.services.mozilla.com/D1836
Consuming the new 'page-visited' notification was fairly trivial,
since it was already brought over to onVisits. There's not much to
say about this other than that I'm a little bit uncertain about
all the hoops we have to jump through to get a JSContext and
GlobalObject from History.cpp (which is discussed in the earlier
commit in the series).
MozReview-Commit-ID: LHaBWSylyLI
Consuming the new 'page-visited' notification was fairly trivial,
since it was already brought over to onVisits. There's not much to
say about this other than that I'm a little bit uncertain about
all the hoops we have to jump through to get a JSContext and
GlobalObject from History.cpp (which is discussed in the earlier
commit in the series).
MozReview-Commit-ID: LHaBWSylyLI
Consuming the new 'page-visited' notification was fairly trivial,
since it was already brought over to onVisits. There's not much to
say about this other than that I'm a little bit uncertain about
all the hoops we have to jump through to get a JSContext and
GlobalObject from History.cpp (which is discussed in the earlier
commit in the series).
MozReview-Commit-ID: LHaBWSylyLI
Consuming the new 'page-visited' notification was fairly trivial,
since it was already brought over to onVisits. There's not much to
say about this other than that I'm a little bit uncertain about
all the hoops we have to jump through to get a JSContext and
GlobalObject from History.cpp (which is discussed in the earlier
commit in the series).
MozReview-Commit-ID: LHaBWSylyLI
These probes will register and record (for the duration of the study only):
* When a tab opens.
* When a tab closes.
* When a tab is selected.
MozReview-Commit-ID: BvknEH0ofS0
These probes will register and record (for the duration of the study only):
* When the user is prompted by the Password Manager
* When the user saves their login information through the Password Manager prompt
* When the user updates their login information through the Password Manager prompt
* When the user uses login information stored by the Password Manager
Both the 'pwmgr' and 'pwmgr_use' probe have an 'extra' field called 'flow_id'. This is a tab identifier. For a given session, flow_id remains constant, even if the tab is moved to a different index within the same window. Tabs at the same index in different windows will have different flow_ids.
MozReview-Commit-ID: CoBNl6lUQmH
These probes will register and record (for the duration of the study only):
* When the library menu opens.
* When the hamburger menu opens.
* When the dotdotdot menu opens.
These will be captured in existing and new windows.
Note: The library panel is dynamically added and removed from the document (see PanelUI.js for where the panel is created and removed), so a listener can't be added to it in advance. However, the library menu "ViewShowing" event bubbles up to the navBar in its default location. A separate listener is needed if it is moved to the overflow panel via Hamburger > Customize.
MozReview-Commit-ID: EBBBgXAQnxE
These probes will register and record (for the duration of the study only):
* When the user clicks on a history link displayed by the urlbar
* When the user clicks on a bookmark link displayed by the urlbar
It should be noted that the same site can be multiple result types at the same time, so there will be times when a bookmark and/or history selection is captured as a result type other than bookmark or history (e.g. 'switchtab', 'autofill' or 'visiturl').
MozReview-Commit-ID: FEKVoaTIkiH
These probes will register and record (for the duration of the study only):
* When a bookmark is added.
* When a bookmark is removed.
* When a bookmark is visited.
Also moved init of study module to later in startup as an idle task to mitigate performance impact. Previously, this patch was failing the browser/base/content/test/performance/browser_startup.js test.
Note for bookmark added/removed: Using the source argument, we can filter out bulk events like from Sync, import, restore, etc.
Note for bookmark visited: This will also fire for the case when the user visits a page directly that happens to be bookmarked. The user doesn't have to "click" on a bookmark.
MozReview-Commit-ID: EYVlTLfVLkd
When the study preference (shield.savant.enabled) is set to true, this will record:
* When an addon begins an install
* When an addon finishes an install
* When an addon is enabled
* When an addon is disabled
* When an addon begins an uninstall
* When an addon finishes an uninstall
MozReview-Commit-ID: J8LoBZVS5iL
