The fallback code in nsPrintJob::DoCommonPrint to create an nsIPrintSettings if
none is passed in is never used, since all callers pass a settings object.
However, to simplify future changes I'd like nsGlobalWindowOuter::PrintOuter to
stop creating and passing in its own default valued nsIPrintSettings object.
This patch makes the fallback code that DoCommonPrint calls do what
nsGlobalWindowOuter::PrintOuter does, and makes the latter stop passing in a
settings object.
This patch also removes nsIWebBrowserPrint.globalPrintSettings since
nsGlobalWindowOuter::PrintOuter was its only consumer.
Differential Revision: https://phabricator.services.mozilla.com/D83268
The mStorageAccessPermissionGranted variable determins the result of
HasStorageAccess API, which should sync with the result of the
ContentBlocking::ShouldAllowAccessFor.
This patch removes using nsGloWindowOuter's logic and alwasys use
ShouldAllowAccessFor while creating a new document.
Differential Revision: https://phabricator.services.mozilla.com/D78634
The mStorageAccessPermissionGranted variable determins the result of
HasStorageAccess API, which should sync with the result of the
ContentBlocking::ShouldAllowAccessFor.
This patch removes using nsGloWindowOuter's logic and alwasys use
ShouldAllowAccessFor while creating a new document.
Differential Revision: https://phabricator.services.mozilla.com/D78634
The mStorageAccessPermissionGranted variable determins the result of
HasStorageAccess API, which should sync with the result of the
ContentBlocking::ShouldAllowAccessFor.
This patch removes using nsGloWindowOuter's logic and alwasys use
ShouldAllowAccessFor while creating a new document.
Differential Revision: https://phabricator.services.mozilla.com/D78634
The mStorageAccessPermissionGranted variable determins the result of
HasStorageAccess API, which should sync with the result of the
ContentBlocking::ShouldAllowAccessFor.
This patch removes using nsGloWindowOuter's logic and alwasys use
ShouldAllowAccessFor while creating a new document.
Differential Revision: https://phabricator.services.mozilla.com/D78634
This removes the diagnostic warnings which used to be logged when the
Large-Allocation header was present, but failed to switch into a
Large-Allocation process. Due to the low adoption of the header, this shouldn't
be too large of a problem, but we can look into re-adding the diagnostics if
needed in the future.
The new codepath no longer performs multiple network requests for
Large-Allocation resources, and now relies on the battle-tested
DocumentLoadListener codepath for process switching.
Differential Revision: https://phabricator.services.mozilla.com/D78998
This removes the diagnostic warnings which used to be logged when the
Large-Allocation header was present, but failed to switch into a
Large-Allocation process. Due to the low adoption of the header, this shouldn't
be too large of a problem, but we can look into re-adding the diagnostics if
needed in the future.
The new codepath no longer performs multiple network requests for
Large-Allocation resources, and now relies on the battle-tested
DocumentLoadListener codepath for process switching.
Differential Revision: https://phabricator.services.mozilla.com/D78998
Adds an |aChromeOnlyDispatch| flag to DispatchCustomEvent to decide whether
to call DispatchTrustEvent or DispatchEventOnlyToChrome.
The following chrome-only events are dispatched with DispatchCustomEvent and now
make use of the flag:
- DOMWindowClose
- fullscreen / willenterfullscreen / willexitfullscreen
- occlusionstatechange
- resolutionchange
- XULAlertClose
and the following were previously dispatched with DispatchTrustedEvent and now
use DispatchEventOnlyToChrome:
- MozBeforeInitialXULLayout
- MozMouseScrollFailed / MozMouseScrollTransactionTimeout
- MozPaintWait / MozPaintWaitFinished
- MozPerformDelayedBlur
- all events fired by APZCCallbackHelper::NotifyMozMouseScrollEvent
Differential Revision: https://phabricator.services.mozilla.com/D76723
Previously we only set some fields as part of WindowGlobalInit, but WindowGlobalParent sets itself as the current window global on the CanonicalBrowsingContext.
This exposes a period of time where only part of the document state was set, and this was observable to consumers.
This makes OnNewDocument only run when there is a new Document for the same WindowGlobal.
Differential Revision: https://phabricator.services.mozilla.com/D75446
Previously we only set some fields as part of WindowGlobalInit, but WindowGlobalParent sets itself as the current window global on the CanonicalBrowsingContext.
This exposes a period of time where only part of the document state was set, and this was observable to consumers.
This makes OnNewDocument only run when there is a new Document for the same WindowGlobal.
Differential Revision: https://phabricator.services.mozilla.com/D75446
We already have an architecture to sync the storage access granted
result to all 3rd-party frames with the same tracking origin.
We use the same way to sync HasStorageAccess flag instead of relying
on permission manager update permissions to child processes.
Differential Revision: https://phabricator.services.mozilla.com/D73711
We already have an architecture to sync the storage access granted
result to all 3rd-party frames with the same tracking origin.
We use the same way to sync HasStorageAccess flag instead of relying
on permission manager update permissions to child processes.
Differential Revision: https://phabricator.services.mozilla.com/D73711
When a new document is loaded in a WindowContext, various pieces of state need
to be updated in the parent process. This is currently done in an ad-hoc manner
in nsGlobalWindowOuter::SetNewDocument. This change moves the updating logic
into a common method on WindowGlobalChild.
Differential Revision: https://phabricator.services.mozilla.com/D74325
The entire CookieJarSettingsArgs is currently being synced into every content
process, when only two fields of that structure are actually needed.
Those two fields are extracted from the CookieJarSettingsArgs and synchronized
separately to avoid leaking information such as principals into every content
process.
Differential Revision: https://phabricator.services.mozilla.com/D74258
The entire CookieJarSettingsArgs is currently being synced into every content
process, when only two fields of that structure are actually needed.
Those two fields are extracted from the CookieJarSettingsArgs and synchronized
separately to avoid leaking information such as principals into every content
process.
Differential Revision: https://phabricator.services.mozilla.com/D74258
Jonathan Watt
Mihai Alexandru Michis
Dimi Lee
Simon Giesecke
Cosmin Sabou
Butkovits Atila
Kris Maglione
Eden Chuang
Csoregi Natalia
Coroiu Cristina
Nika Layzell
Narcis Beleuzu
Kartikaya Gupta
Peter Van der Beken
Andrea Marchesini
Olli Pettay
Kashav Madan
Noemi Erli
Dorel Luca
Erik Nordin
Matt Woodrow
Bogdan Tara
Anny Gakhokidze
Brindusan Cristian