Automatic update from web-platform-tests
Cancel rather than block navigations which violate portals 1P rules.
Since this can lead to a WebContents with no committed entries, deal
with that case in the browser-side Activate logic, by rejecting
activations which occur before we can say with certainty that we
will load a page (i.e. navigation commit).
Bug: 1046121,1034740,942198
Change-Id: Icd219dc0bb1e4a9ab6fdc433f8644c14e69964e4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2015768
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Lucas Gadani <lfg@chromium.org>
Commit-Queue: Jeremy Roman <jbroman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#736369}
--
wpt-commits: 3888d4d05c82a951afb63fd0d20a38bb5ea3bf90
wpt-pr: 21448
Automatic update from web-platform-tests
[Security] Implement the context switch for COOP.
This CL lands the Cross-Origin-Opener-Policy "changes to navigation",
as per: https://gist.github.com/annevk/6f2dd8c79c77123f39797f6bdac43f3e
In practice, it forces a BrowsingInstance switch when we have a COOP
mismatch. This is necessary but not sufficient, as we want to ensure
the following behavior:
(1) window.open() returned WindowProxy is closed when we know that we
need to switch.
(2) opener is null in opened popups.
(3) window.name is empty in opened popups.
This CL solves (2). Currently (1) is untested and will follow in
a different patch (tests under development by pmeuleman@ at
https://github.com/web-platform-tests/wpt/pull/21161) and (2) needs to
be updated with some other state in DidCommit.
Bug: 922191
Change-Id: I7d5169f7d53bfc28ea01a1a03c7658e0645bc492
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1985013
Commit-Queue: Arthur Hemery <ahemery@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#736344}
--
wpt-commits: 2ae8e39b7116213662bcc5357394d4418651211c
wpt-pr: 21191
Automatic update from web-platform-tests
SharedWorker: Remove debug-output in referrer-policy WPT
This CL removes debug-output in referrer-policy web-platform-tests.
This file shouldn't be added but unintentionally included in the CL:
https://chromium-review.googlesource.com/c/chromium/src/+/2023710
Bug: 824646
Change-Id: If0775cebd63d53dd0510b5d64ce2a643998455cf
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2026829
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Commit-Queue: Eriko Kurimoto <elkurin@google.com>
Cr-Commit-Position: refs/heads/master@{#736296}
--
wpt-commits: 074719e3660000659cd074b8a59de69bd9b90cd7
wpt-pr: 21484
Automatic update from web-platform-tests
Stop dispatching SMIL events while seeking
Based on [1], 'beginEvent' and 'endEvent' should only be dispatched for
elements that are active at the seeked-to time and elements that were
active at the previous/old/seeked-from time but are inactive at the
seeked-to time (respectively). 'repeatEvent's should not be disaptched
while seeking.
To handle this, extend the TimingUpdate helper class with a map that
tracks what interval the active elements had before the seek operation,
and whether the timing update operation is a seek operation (called
"fast-forward" since we end up moving in the forward direction
regardless of the actual seek direction).
Apart from that, the dispatching of 'repeatEvent's are also inhibited,
as well as the notifications of repeats in general.
[1] https://www.w3.org/TR/SMIL3/smil-timing.html#q114
Bug: 1039886
Change-Id: I17d91b1355858ee0b916d4fa46b9572e685e40e5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2020947
Reviewed-by: Philip Rogers <pdr@chromium.org>
Commit-Queue: Fredrik Söderquist <fs@opera.com>
Cr-Commit-Position: refs/heads/master@{#736289}
--
wpt-commits: e03feecc468b65aadc66b24bf76dbd0d6acfff5b
wpt-pr: 21432
Since bug 1610260 extended the timeout for wpt ccov tests, these are not
timing out anymore.
Differential Revision: https://phabricator.services.mozilla.com/D62290
--HG--
extra : moz-landing-system : lando
The pendingEdges_ field no longer has to use Maybe<> because we now always
call IonBuilder's destructor.
Differential Revision: https://phabricator.services.mozilla.com/D62014
--HG--
extra : moz-landing-system : lando
For now IonCompileTask just forwards to IonBuilder, but that will change in a
later patch.
Differential Revision: https://phabricator.services.mozilla.com/D62011
--HG--
extra : moz-landing-system : lando
We now no longer allocate a new MIRGenerator for each inline builder. This was
pretty confusing because only the outermost one survived and was used by the
backend.
MIRGenerator's CompileInfo field was renamed from info_ to outerInfo_ to make
this a bit clearer.
Depends on D62009
Differential Revision: https://phabricator.services.mozilla.com/D62010
--HG--
extra : moz-landing-system : lando
For now MIRGenerator and IonBuilder still have the same lifetime, but later
parts will change IonBuilder to a stack-allocated class with a much shorter
lifetime than MIRGenerator.
Some MIRGenerator fields that are accessed frequently by IonBuilder are now
cached in IonBuilder to avoid an extra dereference.
Depends on D62008
Differential Revision: https://phabricator.services.mozilla.com/D62009
--HG--
extra : moz-landing-system : lando
This MIRGenerator flag is not used for inline builders so there's no need to set
it. With later patches in this stack there will be a single MIRGenerator per
compilation so this will become a bit more obvious.
Depends on D62007
Differential Revision: https://phabricator.services.mozilla.com/D62008
--HG--
extra : moz-landing-system : lando
IonBuilder is a better fit for this data. MIRGenerator is used by the backend
and is also used for Wasm compilation and WarpBuilder in the future.
Differential Revision: https://phabricator.services.mozilla.com/D62007
--HG--
extra : moz-landing-system : lando
Moreover, this is potentially more efficient because
`GetRangesForIntervalArray` doesn't have to be called when there's no
frame selection.
Differential Revision: https://phabricator.services.mozilla.com/D62198
--HG--
extra : moz-landing-system : lando
I'm taking the opportunity to remove isDefaultHandlerApp messaging as the
content-side calls were removed in bug 1353029.
Depends on D59788
Differential Revision: https://phabricator.services.mozilla.com/D59789
--HG--
extra : moz-landing-system : lando