Note that the odd path which always returns `NS_ERROR_FAILURE` is not covered by
the tests. Therefore, this patch adds `MOZ_ASSERT` to make somebody hit it and
report a bug.
Differential Revision: https://phabricator.services.mozilla.com/D149108
Looks like with the COEP:credentialless implementation, some anonymous
iframe tests start to fail. I didn't investigate this because we don't
support anonymous iframe at the moment, so it's not worth to look into
it.
Differential Revision: https://phabricator.services.mozilla.com/D149945
Spec: https://fetch.spec.whatwg.org/#ref-for-cross-origin-resource-policy-internal-check
This purpose of this patch is just to implement the spec.
One noticeable thing I did in the patch is I made `CacheResponse` to
include the `credentials mode` of the initial request. Consider the
below scenario:
1. Create a fetch request with a URL and a specific credential_mode, and put it into cache
2. Call cache.match by using a URL, but without credential_mode
3. cache.match() result should be filtered according to the initial request's credential_mode
When applying the `response’s request-includes-credentials is true`
check, the initial request's `credential_mode` is needed because
`request-includes-credentials` is judged by the `credential_mode`.
The rest of the changes are just normal spec alignments.
Differential Revision: https://phabricator.services.mozilla.com/D147803
Spec: https://html.spec.whatwg.org/multipage/#coep:coep-credentialless
Credentialless is a new cross-origin embedder policy which allows us
to not enforcing CORP when loading cross-origin resources while
providing SharedArrayBuffer.
There are two main things involved here:
1. Fetching cross-origin no-CORS resources omits credentials
- This is done by applying `LOAD_ANONYMOUS` flag to the request
2. Other requests sent with credentials require the server's explicit
permission through the CORS protocol or the CORS header
- This is done by expanding `ProcessCrossOriginResourcePolicyHeader`
function to apply the necessary checks.
Differential Revision: https://phabricator.services.mozilla.com/D147802
This disables the outdated, incorrect implementation of the
Reporting API. The current implementation was only enabled
on Nightly builds, but given its current state it does not
even make sense there.
Differential Revision: https://phabricator.services.mozilla.com/D149873
Note that `CSSEditUtils` does not change `Selection` except
`RemoveCSSInlineStyleWithTransaction` which is used only by aligning in a block.
Therefore, this patch does not touch `CSSEditUtils`.
Differential Revision: https://phabricator.services.mozilla.com/D149106
Add an implementation of CSS `contain: style`. This introduces two new
data structures, the ContainStyleScope and ContainStyleScopeManager.
ContainStyleScope manages one `contain: style` "world" which has its own
counter and quote lists. The contents of these lists depend on their
parent scopes, but are not affected by their children.
ContainStyleScopeManager manages a tree of scopes starting at a root
scope which is outside of any `contain: style` element.
Scopes are stored in a hash table that is keyed off of the nsIContent
which establishes the `contain: style` scope. When modifying quote or
content lists, the ContainStyleScopeManager is responsible for finding
the appropriate `contain: style` scope to modify.
Perhaps the most complex part of this is that counters and quotes have
read access to the state of counters and quotes that are in ancestor
`contain: style` scopes. In the case of counters, USE nodes that are at
the beginning of counter lists might have a counter scope that starts in
an ancestor `contain: style` scope. When nsCounterNode::SetScope() is
called, the code may look upward in the `contain: style` scope tree to
find the start of the counter scope. In the case of quotes, the first
node in the quote list must look for the state of quotes in ancestor
`contain: style` scopes.
Differential Revision: https://phabricator.services.mozilla.com/D149508
This matches UWP apps like Settings on Windows 11, and what we do for other
desktop platforms too.
The system colors match the ones from Win32 otherwise, but using UIUtils we can
access the accent color pallete from UWP apps.
Add a pref just to be safe in any case.
Differential Revision: https://phabricator.services.mozilla.com/D149905
It'd be weird otherwise, as in platforms where use-theme-accent is false
(Windows), form controls would be blue (the default accent color) but
the AccentColor color would be the system accent color still.
Differential Revision: https://phabricator.services.mozilla.com/D149877
The link was missing an event listener, that we add in this patch.
A test case is added to make sure the link does work.
Differential Revision: https://phabricator.services.mozilla.com/D149953
Automatic update from web-platform-tests
Properly handle floats leaving an inline formatting context.
Revert all code changes from CL:3613771 and replace with this. The bad
CL just did SetIsInLayoutNGInlineFormattingContext(false), which would
leave fragment items behind pointing to layout objects. When such a
layout object would later on be deleted, the fragment items wouldn't be
notified, since IsInLayoutNGInlineFormattingContext was false.
Notify the fragment items that layout object becoming in-flow
non-floated will be "moved", to properly clear the association. There
was already code for this when going out-of-flow, but we also need this
when becoming in-flow non-floated.
Bug: 1331189
Change-Id: I888d81495627952b75ec33a83edce165f6a3ad01
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3714111
Commit-Queue: Koji Ishii <kojii@chromium.org>
Reviewed-by: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1016000}
--
wpt-commits: d0cc6394218081bea51fc0352cd521fbf1fc1f47
wpt-pr: 34498
