Which is the spec term. nsIStyleSheetLinkingElement is even more
confusing since it may not be an element at all (see: processing
instructions).
Differential Revision: https://phabricator.services.mozilla.com/D76071
This corrects the handling of user-scalable=no to first clamp scale (whether
specified or default) between min and max scales, then applies the resulting
value to initial-scale, min and max.
Differential Revision: https://phabricator.services.mozilla.com/D76056
This patch makes the triggering princpal to be propagated to the
BrowserChild when calling LoadURL in nsFrameLoader. And use it as the
triggering principal for loading instead of the system principal.
Differential Revision: https://phabricator.services.mozilla.com/D75965
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
Before this patch, we only call StorageAccessGranted on windows that
triggers the storage heuristics. So even if we sync storage permission to the
other frames, their data will not be refreshed. For example, if a document
has a worker, we don't propagate the permission to the worker.
In this patch, we call ::StorageAccessGranted as long as we update
the window's storage permission.
Differential Revision: https://phabricator.services.mozilla.com/D74321
Before this patch, in non-fission mode, we cache storage access granted result
in the top-level window so we don't have to iterate all the browsing contexts
in the same tree while syncing the storage permission granted decision.
However, since we plan to rely on the current update mechanism to sync
mHasStorageAccess flag for different documents in the same tab (instead of using
the syncing mechanism of permission manager), we will eventually need to iterate
the browsing context tree to find all the documents to sync. Base on this,
we no longer have to maintain different method for fission and non-fission.
In this patch, we store the permission granted result in the inner
window instead of using permission key and store the key in the top-level
window.
Differential Revision: https://phabricator.services.mozilla.com/D73710
The Mac focus model is a bit different (mouse doesn't focus form
controls for example).
This matches GTK3 to my knowledge, where outlines are not shown until
you've navigated with the keyboard.
We should maybe consider changing Android as well (and maybe all
platforms, actually), but that's a bit of a bigger endeavour.
Differential Revision: https://phabricator.services.mozilla.com/D75505
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
Before this patch, we only call StorageAccessGranted on windows that
triggers the storage heuristics. So even if we sync storage permission to the
other frames, their data will not be refreshed. For example, if a document
has a worker, we don't propagate the permission to the worker.
In this patch, we call ::StorageAccessGranted as long as we update
the window's storage permission.
Differential Revision: https://phabricator.services.mozilla.com/D74321
Before this patch, in non-fission mode, we cache storage access granted result
in the top-level window so we don't have to iterate all the browsing contexts
in the same tree while syncing the storage permission granted decision.
However, since we plan to rely on the current update mechanism to sync
mHasStorageAccess flag for different documents in the same tab (instead of using
the syncing mechanism of permission manager), we will eventually need to iterate
the browsing context tree to find all the documents to sync. Base on this,
we no longer have to maintain different method for fission and non-fission.
In this patch, we store the permission granted result in the inner
window instead of using permission key and store the key in the top-level
window.
Differential Revision: https://phabricator.services.mozilla.com/D73710
Instead move the check to the focus manager, more similar to how
focus-visible works.
Now nsGlobalWindowInner::ShouldShowFocusRing means "Should we show focus
ring for anything in this window", that is: Have we keyboard-navigated
in this window, or do we have a pref that says that we should always
show focus rings.
Fix some callers appropriately (some of them that were not properly
accounting for the element being focused in the first place...).
Differential Revision: https://phabricator.services.mozilla.com/D75504
ChromeUtils::requestProcInfo was dropping thread names for the process process. This patch restores them and tests that at least *one* thread is named. Unfortunately, at the time of this writing, we cannot assume that *all*
threads are named. Investigation pending.
Differential Revision: https://phabricator.services.mozilla.com/D75420
This patch will do :
- create a sync field `AutoplayPermission` on WindowContext
- update the field whenever site's the autoplay permission changes
The advantage of doing so :
- to help determine the result of the blocking autoplay correctly.
More details :
As the field would be automatically synced between processes, then we can know the correct site's autoplay permission for the whole page even if we're in the different process if the iframe is in different origin after we enable Fission.
Differential Revision: https://phabricator.services.mozilla.com/D74511
Instead move the check to the focus manager, more similar to how
focus-visible works.
Now nsGlobalWindowInner::ShouldShowFocusRing means "Should we show focus
ring for anything in this window", that is: Have we keyboard-navigated
in this window, or do we have a pref that says that we should always
show focus rings.
Fix some callers appropriately (some of them that were not properly
accounting for the element being focused in the first place...).
Differential Revision: https://phabricator.services.mozilla.com/D75504
ChromeUtils::requestProcInfo was dropping thread names for the process process. This patch restores them and tests that at least *one* thread is named. Unfortunately, at the time of this writing, we cannot assume that *all*
threads are named. Investigation pending.
Differential Revision: https://phabricator.services.mozilla.com/D75420
This also requires changing the EffectCompositor to allow animations in print
and print preview, and setting up a document timeline for the cloned document
Differential Revision: https://phabricator.services.mozilla.com/D69069
In RFP mode, canvas image extraction leads to an all-white image, replace that
with a random (sample 32 bytes of randomness and fill the buffer with that)
'poison pill'. This helps defeat naive fingerprinters by producing a random
image on every try. This feature is toggled using a new, default on, pref
`privacy.resistFingerprinting.randomDataOnCanvasExtract`.
Updated `browser_canvas_fingerprinting_resistance.js` to test this new feature
as well.
Updates and replaces D66308.
Differential Revision: https://phabricator.services.mozilla.com/D72716
The location wasn't used from the caller of
`GetTableCellLocationFromRange`.
However, `GetTableCellLocationFromRange`
included flushing frames, this is now done in
`HTMLEditor::CellIndexes::Update`.
Differential Revision: https://phabricator.services.mozilla.com/D75098
nsContentUtils::IsPatternMatching calls into SpiderMonkey several times to validate and execute a regexp. It assumes that JS::NewUCRegExpObject can only fail if the pattern is invalid. However, in the case of OOM or stack overflow, this is false.
In the previous patch, we added a new API for pattern matching. This patch uses the new function to clean up the error handling in IsPatternMatching.
Differential Revision: https://phabricator.services.mozilla.com/D74501
We can reduce the size of the SSO by removing the element slot entirely, and instead retrieve the element through a callback function. The callback will take in the value in the private slot of the SSO, which is either a LoadedScript* (from the browser) or a JSObject* (from the shell). In addition, this removes the requirement of having a script dom element ready when parsing a JS script which can open up new opportunities for performance.
Differential Revision: https://phabricator.services.mozilla.com/D70417
nsContentUtils::IsPatternMatching calls into SpiderMonkey several times to validate and execute a regexp. It assumes that JS::NewUCRegExpObject can only fail if the pattern is invalid. However, in the case of OOM or stack overflow, this is false.
In the previous patch, we added a new API for pattern matching. This patch uses the new function to clean up the error handling in IsPatternMatching.
Differential Revision: https://phabricator.services.mozilla.com/D74501
That is, drop the reference to the sheet pointer. GetModifiableMapped
doesn't ever return anything that's on the hash. But trying to
DropMappedAttributes it will remove not that instance, but any other
instance that's already in the hash and matches it.
ThisDropSheetReference is always done in MakeMappedUnique if relevant.
On the original test-case it was about the -moz-user-modify property
that contenteditable maps, but it reproduces with any mapped attribute
like hidden, so I used that for WPT.
Differential Revision: https://phabricator.services.mozilla.com/D74498
nsContentUtils::IsPatternMatching calls into SpiderMonkey several times to validate and execute a regexp. It assumes that JS::NewUCRegExpObject can only fail if the pattern is invalid. However, in the case of OOM or stack overflow, this is false.
In the previous patch, we added a new API for pattern matching. This patch uses the new function to clean up the error handling in IsPatternMatching.
Differential Revision: https://phabricator.services.mozilla.com/D74501
This patch persists the CrossOriginEmbedderPolicy on the Document and
WindowContext.
The WindowContext's embedder policy is set in
WindowGlobalActor::BaseInitializer by either adopting the policy of the HTTP
channel that loaded the document, or in WindowGlobalChild::OnNewDocument
by inheriting the one from the browsingContext's windowContext.
Differential Revision: https://phabricator.services.mozilla.com/D46903
Allows defriending `AutoScroller` from `Selection` and removes the
direct dependency of `AutoScroller` to `Selection`.
Differential Revision: https://phabricator.services.mozilla.com/D74382
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
In RFP mode, canvas image extraction leads to an all-white image, replace that
with a random (sample 32 bytes of randomness and fill the buffer with that)
'poison pill'. This helps defeat naive fingerprinters by producing a random
image on every try. This feature is toggled using a new, default on, pref
`privacy.resistFingerprinting.randomDataOnCanvasExtract`.
Updated `browser_canvas_fingerprinting_resistance.js` to test this new feature
as well.
Updates and replaces D66308.
Differential Revision: https://phabricator.services.mozilla.com/D72716
This variant was only used for service workers' openWindow method, which has
been changed to no longer behave in this way, meaning that the type can be
removed. The follow-up simplification of removing
'ContentChild::ProvideWindowCommon', and moving the logic directly into
'BrowserChild' is not done in this bug, and will be done in a follow-up instead.
Differential Revision: https://phabricator.services.mozilla.com/D72935
This variant was only used for service workers' openWindow method, which has
been changed to no longer behave in this way, meaning that the type can be
removed. The follow-up simplification of removing
'ContentChild::ProvideWindowCommon', and moving the logic directly into
'BrowserChild' is not done in this bug, and will be done in a follow-up instead.
Differential Revision: https://phabricator.services.mozilla.com/D72935
With LazyFC in the parent process enabled, we can get here more easily
without frames for the <browser> element.
This causes some assertion failures because we start parenting the
remote browsers to the wrong layer manager when inside a popup.
If we get to nsFrameLoader::TryRemoteBrowser without a frame,
GetLayerManager (which uses GetWidgetForContent) will just fall back to
GetWidgetForDocument. Badness ensues if the widget should actually not
be that one.
Make sure to flush frames when we load an event, so that we can
initialize stuff properly.
We could try to only flush if inside a popup or something, but this code
is a bit tricky so if possible I'd prefer not to diverge.
Differential Revision: https://phabricator.services.mozilla.com/D74177
This removes processing of HTTP Public Key Pinning headers, remotely modifying
pinning information, and using cached pinning information, all of which was
already disabled in bug 1412438. Static pins that ship with the browser are
still enforced.
Differential Revision: https://phabricator.services.mozilla.com/D73352
This variant was only used for service workers' openWindow method, which has
been changed to no longer behave in this way, meaning that the type can be
removed. The follow-up simplification of removing
'ContentChild::ProvideWindowCommon', and moving the logic directly into
'BrowserChild' is not done in this bug, and will be done in a follow-up instead.
Differential Revision: https://phabricator.services.mozilla.com/D72935
THis should continue allowing users to zoom out in RDM mode, or any time that
we are respecting the meta-viewport tag. It's only when we don't respect the
meta-viewport tag that we disable zooming out past initial zoom.
Differential Revision: https://phabricator.services.mozilla.com/D73461
This removes the need for FrameForPointOptions::IsRelativeToLayoutViewport,
and makes sure each call site of these functions indicates whether the
input point/rect is in visual or layout coordinates.
Several call sites were passing in layout coordinates without setting the
IsRelativeToLayoutViewport flag, which this patch corrects.
Differential Revision: https://phabricator.services.mozilla.com/D71705
This "upgrades" various nsLayoutUtils functions which take as inputs
a set of coordinates and a frame that the coordinates are relative to,
to accept a RelativeTo object instead of a frame.
Most of the patch is just dumb propagation, but the few places where
we use an explicit ViewportType::Visual are important. There are
probably a few other places I've overlooked, but this seems to cover
the important ones that come up commonly.
There are undoubtedly other functions into which we can propagate
RelativeTo, in this patch I've propagated it as far as necessary
for my needs in this bug (mainly GetTransformToAncestor() and
GetEventCoordinatesRelativeTo()).
Differential Revision: https://phabricator.services.mozilla.com/D68919
Raw Cr.ERROR don't get stack information, same as throwing JS literals instead
of `new Error()`s.
This was done automatically with a new eslint rule that will be introduced in
the next commit. One instance of a raw Cr.ERROR was not replaced since it is
used in a test that specifically checks the preservation of raw Cr values in
XPCJS. The rule will be disabled for that instance.
Differential Revision: https://phabricator.services.mozilla.com/D28073
Instead of manually defining toStringTag we now add the toStringTag symbol to the list of properties.
This is also how we usually define toStringTag in the JS engine.
Even though this changes more code I like this approach better. Everything is centralized in the generated bindings file.
Differential Revision: https://phabricator.services.mozilla.com/D72179
The cast in InitWithNode is wrong. AsElement() asserts instead of
checking the flag, so we always pass an element (and if we didn't we'd
have type confusion problems). I audited the callers and we're fine.
Anyhow, always require an element, and add two convenience constructors
for C++ code.
Differential Revision: https://phabricator.services.mozilla.com/D73636
The cast in InitWithNode is wrong. AsElement() asserts instead of
checking the flag, so we always pass an element (and if we didn't we'd
have type confusion problems). I audited the callers and we're fine.
Anyhow, always require an element, and add two convenience constructors
for C++ code.
Differential Revision: https://phabricator.services.mozilla.com/D73636
We set opener policy from the channel of the new document when creating a
WindowGlobalChild. However, we need to check if it's crossOriginIsolated even
when the WindowGlobalChild hasn't been created for the new inner window in some
cases.
To avoid checking the unset value of opener policy from the BrowsingContext,
this patch moves the setting the opener policy right before creating a native
global for a new inner window. So that the value of opener policy should always
be correct when validating it (IsSharedMemoryAllowed).
Differential Revision: https://phabricator.services.mozilla.com/D71534
Previously the BrowsingContext was also being sent down, despite it being
obvious from the PBrowserBridge actor which the message was sent over.
Differential Revision: https://phabricator.services.mozilla.com/D72929
This provides web compatability with Chrome's interpretation of the spec at
https://drafts.csswg.org/css-device-adapt/#user-zoom-desc. This changes makes
us treat "the user cannot interactively change the zoom factor" as inclusive
of ANY method of the user agent changing zoom levels, regardless of whether or
not the user initiated an action.
So, in addition to preventing things like double-tap-to-zoom and pinch-zoom,
this change prevents zoom changes to fit all content into the viewport, or to
maintain visible content proportionality if the viewport is resized dynamically.
This also adds an assert to cases where Document::GetViewportInfo returns a
viewport with a non-positive scale factor that it also sets the auto scale
flag.
This also adds a tentative web-platform test.
Differential Revision: https://phabricator.services.mozilla.com/D72004
We can reduce the size of the SSO by removing the element slot entirely, and instead retrieve the element through a callback function. The callback will take in the value in the private slot of the SSO, which is either a LoadedScript* (from the browser) or a JSObject* (from the shell). In addition, this removes the requirement of having a script dom element ready when parsing a JS script which can open up new opportunities for performance.
Differential Revision: https://phabricator.services.mozilla.com/D70417
Even in comm-central and BlueGriffon, `nsISelectionController::*ForDelete()`
are not used. Therefore, we can remove them safely.
Differential Revision: https://phabricator.services.mozilla.com/D72296
In Document::HasStorageAccess(), we try to get the top-level document.
To check if the document is first-party to the top-level document. But,
this won't work for Fission since the top-level document could be
out-of-process.
In this patch, we use broswing context to get the top-level principal to
test if the document is thrid-party. If we cannot get the top-level
outer window, the top-level document should be cross-origin. So, we know
the answer. If the top-level document is available, we check the
principal to see if the document is first-party.
Differential Revision: https://phabricator.services.mozilla.com/D72664
This adds a splits the non-incremental threshold parameter into one for small heaps and one for large. What counts as large and small are controlled by the existing parameters that were previously used for dynamic heap growth. I also renamed the parameter from "non-incremental threshold" to "incremental limit".
The small heap parameter is increased to 1.4. This avoids non-incremental GC on facebook and reddit as reported in the dependent bugs and allows us to remove the splay latency hack that was previously necessary.
Differential Revision: https://phabricator.services.mozilla.com/D72903
In Document::HasStorageAccess(), we try to get the top-level document.
To check if the document is first-party to the top-level document. But,
this won't work for Fission since the top-level document could be
out-of-process.
In this patch, we use broswing context to get the top-level principal to
test if the document is thrid-party. If we cannot get the top-level
outer window, the top-level document should be cross-origin. So, we know
the answer. If the top-level document is available, we check the
principal to see if the document is first-party.
Differential Revision: https://phabricator.services.mozilla.com/D72664
- Add functions for traversing stylesheets in DocumentOrShadowRoot
- Add functions for unlinking stylesheets in DocumentOrShadowRoot
- Traverse and Unlink Document::mAdditionalSheets
Differential Revision: https://phabricator.services.mozilla.com/D72708
We don't access HasStoragePermission across process, so we don't need to
store the permission in WindowContext.
After this patch, HasStoragePermission will only be stored in the
channel's LoadInfo, which is set when a channel is created in the parent
and it won't be updated.
Depends on D71985
Differential Revision: https://phabricator.services.mozilla.com/D72305
There are two places where we save storage permission:
1. LoadInfo hasStoragePermission attribute
2. mStorageAccessGranted in nsPIDOMWindowInner
For LoadInfo.hasStoragePermission, it is set during channel creation and
its value remains the same even when the storage permission is granted
afterward.
The updated storage permission for a window is saved in
mStorageAccessGranted, which has a different meaning for fission and
non-fission mode.
In non-fission mode, mStorageAccessGranted is saved in the top-level
window and it is an array containing all tracking subframes that
are allowed to access storage.
In fission mode, mStorageAccessGranted is set in individual tracking
windows that we have granted its storage permission. Although it works
like a boolean flag in fission, we still keep using an array to compatible
with the use case in non-fission mode.
Depends on D71984
Differential Revision: https://phabricator.services.mozilla.com/D71985
In Document::HasStorageAccess(), we try to get the top-level document.
To check if the document is first-party to the top-level document. But,
this won't work for Fission since the top-level document could be
out-of-process.
In this patch, we use broswing context to get the top-level principal to
test if the document is thrid-party. If we cannot get the top-level
outer window, the top-level document should be cross-origin. So, we know
the answer. If the top-level document is available, we check the
principal to see if the document is first-party.
Differential Revision: https://phabricator.services.mozilla.com/D72664
In Document::HasStorageAccess(), we try to get the top-level document.
To check if the document is first-party to the top-level document. But,
this won't work for Fission since the top-level document could be
out-of-process.
In this patch, we use broswing context to get the top-level principal to
test if the document is thrid-party. If we cannot get the top-level
outer window, the top-level document should be cross-origin. So, we know
the answer. If the top-level document is available, we check the
principal to see if the document is first-party.
Differential Revision: https://phabricator.services.mozilla.com/D72664