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
This allows keyboard shortcuts containing both "Ctrl" and "Alt" in the
manifest of webextensions (in the "commands" -> "suggested_key" key),
rather than just one of these modifiers. The equivalent combinations
on MacOS (any two of "Command", "Alt" and "MacCtrl") are also allowed.
Non-sensical combinations (such as "Ctrl+Command" or "Ctrl+Ctrl") are
forbidden.
MozReview-Commit-ID: 59tC2efLm5q
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
When ExtensionStorageIDB.selectBackend is called from a child process, it calls the main process
and cache the result as a promise, to be reused for the other contexts for the same extension
that are running in the same process.
The cached promise should not be tied to a particular extension context's cloneScope, otherwise
accessing it will raise "can't access dead object" errors after that cloneScope has been
destroyed.
MozReview-Commit-ID: GJuul8sQmlF
`browser.cookies.getAll(details)` is expected to return all cookies if the
"details.firstPartyDomain" key is set to undefined/null.
This usually works, because `getCookiesWithOriginAttributes` is used,
which iterates over all cookies and only checks origin attributes that
exist in the specified pattern.
If a "url" or "domain" are set, then `getCookiesFromHost` was used,
which uses a look-up table keyed by host and OriginAttributes, with
undefined origin attributes initialized at their default value.
Consequently, only non-FP cookies were returned.
This commit fixes the issue by using `getCookiesWithOriginAttributes`
when the `firstPartyDomain` does not have an explicit (string) value.
MozReview-Commit-ID: AxHbbDeqSwr
The test coverage for cookies.get was incomplete, as scenarios
with empty, null and undefined firstPartyDomain were not checked.
There is a distinction between "empty" and "w/o firstPartyDomain".
MozReview-Commit-ID: 1l54nUOCneK
When a background page has a messaging listener but the background page
is started in response to something other than an extension message, we
were missing the background "startup" event. Fix that by setting up the
listener earlier.
MozReview-Commit-ID: Cr58EyCoY6W
This patch defined a new ExtensionStorageIDB module, which provides the
same "internal" API currently provided by ExtensionStorage and uses
IndexedDB as its backend (instead of the JSONFile used as the backend
provided by ExtensionStorage).
MozReview-Commit-ID: DsvPudExcyr
Creating these promises from ext-toolkit.js was always dicey since that
script is loaded asynchronously during startup. This should ensure that
the startup promises are reliably created early enough in startup.
MozReview-Commit-ID: A0V7iCOFNI8
