This prevents a specific failure in the "browser_startup_flicker.js" test on Windows 10 only, surfaced by bug 1421433. The compact theme stylesheet is kept separate because it can be disabled independently.
MozReview-Commit-ID: 3WDkrYqZtqN
The menuitem used to be only included in the markup for the non-browser window
case. This changes it to include it as a hidden <menuitem> for the browser window
case, and then unhide it for the non-browser window case.
MozReview-Commit-ID: 8tY3GiTFmqe
The key used to be removed from the markup. This changes it to include
the <key> but instead disable it through the related command, which fits
the pattern used with other commands.
MozReview-Commit-ID: LPuwULDt22W
It's currently in macWindow.inc.xul which means it gets created for
all non-browser windows, but it's only ever set up for the hidden window.
MozReview-Commit-ID: LeXjKihPRYB
In practice this is an easy fix, just clear the icon when the page first changes
to a new URL. In practice that breaks our hack for setting an early favicon for
certain in-content pages so we have to workaround that somewhat.
Differential Revision: https://phabricator.services.mozilla.com/D1909
This is never referenced in non-OSX, so don't build the file at all,
and remove the preprocessor directive from the file itself.
MozReview-Commit-ID: IqhSuZWxbkJ
This is a quick-and-dirty port. It might be nice to replace
SpecialPowersObserver with the webextensions content script injection
system at some point, but that isn't practical right now (since WE experiments
cannot implement new APIs visible to content scripts).
MozReview-Commit-ID: GinCu3VcbWK
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
