There are several ways that expanded principals can be used as triggering
principals for requests. While that works fine for security checks, it also
sometimes causes them to be inherited, and used as result principals in
contexts where expanded principals aren't allowed.
This patch changes our inheritance behavior so that expanded principals are
downgraded to the most appropriate constituent principal when they would
otherwise be inherited.
The logic for choosing the most appropriate principal is a bit suspect, and
may eventually need to be changed to always select the last whitelist
principal, but I chose it to preserve the current principal downgrade behavior
used by XMLHttpRequest for the time being.
MozReview-Commit-ID: 9fvAKr2e2fa
Minor note:
reftests should've turned off uploadEnabled in the first place.
reftests should have unified telemetry on. It's the future.
MozReview-Commit-ID: 9spzuUAXwwP
This works by allowing an extension to set a value of Services.perms.DENY_ACTION
for permissions.default.desktop-notification, which stores the default permission
for desktop notifications. This means that if no permissions have been explicitly
set for a given page, the default will be used, but if a user overrides the permissions
for a specific page then their chosen permission will override this default.
An extension can only use this to make the default behaviour to disable notifications.
It cannot be used to globally enable notifications.
MozReview-Commit-ID: H5bDZe1ICiC
In cases where data transfer finishes immediately after we close a request, we
can sometimes wind up overwriting that state information with
"finishedtransferringdata", which allows scripted callers to break certain
invariants and cause crashes.
MozReview-Commit-ID: Do3GttF3M9S
It currently isn't possible to suspend a channel from onHeadersReceived for a
cached response. And since it's not possible to add a new stream filter after
a response has started, adding a stream filter at that point will crash if the
channel is still registered.
This test is a basic sanity check for that scenario.
MozReview-Commit-ID: ALYUtxX7mci
This patch changes the behavior of the downloads.download API's saveAs option. Previously, the behavior when neither value is provided (the "default behavior") was not defined by our documentation or Chrome's. Now, the default behavior is changing to rely on the Firefox "Save As" pref (browser.download.useDownloadDir). If Firefox is configured to open the "Save As" dialog for all downloads (browser.download.useDownloadDir == false), that behavior will be the default for the downloads.download API. Otherwise, the default behavior will be not to show the dialog.
This patch also moves some test functionality out of test_chrome_ext_downloads_saveAs.html. Previously, that test would test the saveAs option and also the conflictAction:"uniquify" option. In order to add testing for the new default behavior, it was necessary to move the testing of the conflictAction:"uniquify" option to a new test: test_chrome_ext_downloads_uniquify.html
MozReview-Commit-ID: u6VA4kexlr
Prior to this, if getLevelOfControl was called before the setting was defined to the EPM, an
exception was thrown. This fixes it by returning a level of control of "not_controllable"
if the setting has not yet been defined.
MozReview-Commit-ID: 96jXLoJlUI
