Sorry this is not a particularly easy patch to review. But it should be
mostly straight-forward.
I kept Document::Dispatch mostly for convenience, but could be
cleaned-up too / changed by SchedulerGroup::Dispatch. Similarly maybe
that can just be NS_DispatchToMainThread if we add an NS_IsMainThread
check there or something (to preserve shutdown semantics).
Differential Revision: https://phabricator.services.mozilla.com/D190450
`nsDocShellLoadState::IsExemptFromHTTPSOnlyMode` is currently only used by HTTPS-First. It is used for fixing upgrade-downgrade loops and when loading history entries, as when we already know if HTTPS-First succeeded there or not, we have no need for trying to upgrade again and can disable HTTPS-First. With the changes introduced by Bug 1839612, `nsDocShellLoadState::IsExemptFromHTTPSOnlyMode` also applies to HTTPS-Only, which is a problem because disabling HTTPS-Only for history entries will result in them potentially being loaded insecurely without the user setting an exception. As a solution this patch just applies `nsILoadInfo::HTTPS_ONLY_EXEMPT_NEXT_LOAD`, the flag being set when `nsDocShellLoadState::IsExemptFromHTTPSOnlyMode` is set, when HTTPS-First is enabled, and renames both flags to reflect that behavior.
Differential Revision: https://phabricator.services.mozilla.com/D185829
In some edge cases, we may start handling user input events that
are not supposed to be handled by the current document.
This patch introduces some delay to handle user input events.
Differential Revision: https://phabricator.services.mozilla.com/D180976
In some edge cases, we may start handling user input events that
are not supposed to be handled by the current document.
This patch introduces some delay to handle user input events.
Differential Revision: https://phabricator.services.mozilla.com/D180976
In some edge cases, we may start handling user input events that
are not supposed to be handled by the current document.
This patch introduces some delay to handle user input events.
Differential Revision: https://phabricator.services.mozilla.com/D180976
This probably should have been done earlier, but became obvious with uses of Document::HasStorageAccessPermissionGrated in this stack.
Differential Revision: https://phabricator.services.mozilla.com/D184825
In the Storage Access API's latest draft, a few items were added to the user-agent state. Relevant here,
the source snapshot params gained two fields that are initialized from the sourceDocument during
snapshotting source params while navigating: "has storage access" and "environment id".
https://privacycg.github.io/storage-access/#ua-state
These are used to identify self-initiated navigations that come from documents that have obtained storage access.
Combined with a same-origin check, this determines if the destination document of the navigation should start
with storage access.
This is stricter than the current behavior, where if the permission is available, all documents start with storage access.
Instead, now a document will only have storage access if it requests it explicitly or if a same-origin document that has
storage access navigates itself to that document. This is seen as a security win.
Security discussion of this change was here: https://github.com/privacycg/storage-access/issues/113
Artur at Google wrote up a great summary here: https://docs.google.com/document/d/1AsrETl-7XvnZNbG81Zy9BcZfKbqACQYBSrjM3VsIpjY/edit#
Differential Revision: https://phabricator.services.mozilla.com/D184821
This probably should have been done earlier, but became obvious with uses of Document::HasStorageAccessPermissionGrated in this stack.
Differential Revision: https://phabricator.services.mozilla.com/D184825
In the Storage Access API's latest draft, a few items were added to the user-agent state. Relevant here,
the source snapshot params gained two fields that are initialized from the sourceDocument during
snapshotting source params while navigating: "has storage access" and "environment id".
https://privacycg.github.io/storage-access/#ua-state
These are used to identify self-initiated navigations that come from documents that have obtained storage access.
Combined with a same-origin check, this determines if the destination document of the navigation should start
with storage access.
This is stricter than the current behavior, where if the permission is available, all documents start with storage access.
Instead, now a document will only have storage access if it requests it explicitly or if a same-origin document that has
storage access navigates itself to that document. This is seen as a security win.
Security discussion of this change was here: https://github.com/privacycg/storage-access/issues/113
Artur at Google wrote up a great summary here: https://docs.google.com/document/d/1AsrETl-7XvnZNbG81Zy9BcZfKbqACQYBSrjM3VsIpjY/edit#
Differential Revision: https://phabricator.services.mozilla.com/D184821
We have more readable and faster versions (that just omit the namespace
arg).
Mostly done via sed, with a couple helpers to use the faster lookups
where possible.
Differential Revision: https://phabricator.services.mozilla.com/D181795
It's a security risk such that the maximized external program can obscure
the fullscreen notification and the malicious site can use this trick
to load a spoofed page in the background without user notices it.
This patch minimized the risk by always exit the fullscreen mode when
an external protocol is triggered.
Differential Revision: https://phabricator.services.mozilla.com/D177771
It's a security risk such that the maximized external program can obscure
the fullscreen notification and the malicious site can use this trick
to load a spoofed page in the background without user notices it.
This patch minimized the risk by always exit the fullscreen mode when
an external protocol is triggered.
Differential Revision: https://phabricator.services.mozilla.com/D177771
This comes from bug 890195, and it was superseded by bug 1575097.
This isn't used for anything anymore, and we can remove the otherwise unused
MediaFeatureChangeReason flag as well.
Differential Revision: https://phabricator.services.mozilla.com/D174492
These types were already non-nullable, with the serializer implementation not
supporting nullptr values. This patch converts the uses to be explicitly
non-nullable, and adds the relevant `WrapNotNull` changes.
Differential Revision: https://phabricator.services.mozilla.com/D168890
