When the debugger creates a `RematerializedFrame` for an Ion frame, we need to invalidate
the Ion frame to ensure the rematerialized frame is destroyed in `FinishBailoutToBaseline`
(or the exception handler).
The debugger code could fail with OOM before doing this invalidation and in this case we
left a rematerialized frame in the activation's map after returning from the Ion frame.
Differential Revision: https://phabricator.services.mozilla.com/D208774
Note that this can't easily be unit-tested, because the tests can't
distinguish between the real `ENOSYS` from lack of kernel support and
the fake `ENOSYS` from the sandbox.
Differential Revision: https://phabricator.services.mozilla.com/D208823
This change utilizes components.conf to distinguish between the contract implementations of nsISessionStoreFunctions per platform.
Differential Revision: https://phabricator.services.mozilla.com/D206904
This feature is added as "recommended", and added to every presets. This will
allow us to disable it if we really want to.
If the "native allocations" feature is enabled, we still force the installation
of the memory hooks even if we don't have this feature to not break the native
allocations feature.
Differential Revision: https://phabricator.services.mozilla.com/D206789
Otherwise we start painting the window too early, which after
bug 1891063 causes the non-client area to be filled, but we don't paint
anything on top.
Differential Revision: https://phabricator.services.mozilla.com/D208898
Automatic update from web-platform-tests
Fix some view transitions crashtests (#45924)
They are currently written as reftests with reftest-wait and friends, convert them to use test-wait.
--
wpt-commits: 6ae7875d4162f8178de4bdce3da56887bce673e4
wpt-pr: 45924
Automatic update from web-platform-tests
Delete dragdrop_support.js from web platform tests.
The helper functions are redundant as they implement no extra logic.
So, removing these functions and replacing them by adding logs and
event listeners directly.
Bug: 336911513
Change-Id: Icebc99f432ff279c19cbe95e96143b9d67dbf67a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5487578
Commit-Queue: Kashish Jain <kashishjain@microsoft.com>
Reviewed-by: Sanket Joshi <sajos@microsoft.com>
Reviewed-by: Anupam Snigdha <snianu@microsoft.com>
Reviewed-by: Christine Hollingsworth <christinesm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1293052}
--
wpt-commits: e29076d88b6749880683bc10817a0942ca61152b
wpt-pr: 45908
Automatic update from web-platform-tests
Make setting defaultValue from a trusted input event validate
This adds a large-ish test of the validation behavior of the
textarea element, which as far as I can tell is under-specified,
or at least I could not find this behavior in the spec. I looked
mainly here:
https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#validity-states
In particular, there are some interesting differences in the
validity of initially-empty vs initially-non-empty textareas.
This CL, though, also aligns the behavior of Chromium with both
WebKit and Gecko in the specific case where the `input` event
handler sets textarea.defaultValue. In that case, the textarea
will be validated correctly. Previous to this CL, Chromium would
not validate the textarea as a result of the change.
Fixed: 333940413
Change-Id: Iec38fb510296d34419b7ed3df8ab396d2d737d69
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5463568
Auto-Submit: Mason Freed <masonf@chromium.org>
Reviewed-by: David Baron <dbaron@chromium.org>
Commit-Queue: David Baron <dbaron@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1293030}
--
wpt-commits: 3dad9a8b7f17fa61262de8713c6db4dac1c227c5
wpt-pr: 45776
Automatic update from web-platform-tests
Plumbing for new pagination fragment structure.
Previously each page would be represented by a single page fragment
(fragmentainer) with all the document contents inside. However, in order
to support @page properties and margins, we need something more
advanced.
Split the page fragment into three fragments: page container, page
border box, and page area. A page area will always be a child of a page
border box, which in turn will always be a child of a page container.
Page containers are direct children of the LayoutView fragment.
A page container will represent the containing block of a page. It
represents the entire sheet of paper (when printing one page per sheet).
A page border box is simply the border box size of a page. It will be
responsible for painting any effects caused by @page properties - except
the background, which should cover the entire page container.
A page area is a fragmentainer. It contains a portion of the fragmented
document.
See https://drafts.csswg.org/css-page-3/#page-model
For now, all these fragments have the same size, since margins are still
handled on the outside of Blink (e.g. printing::PrintRenderFrameHelper).
This will change in upcoming CLs.
In order for these new fragments to be able to paint anything, they need
a BlockNode (LayoutObject). A BlockNode will also be required in order
to resolve lengths in the standard way, using length_utils (upcoming
CL). These layout objects will not be attached to the layout tree (i.e.
under the LayoutView), since we cannot mutate the layout tree during
layout, and besides they wouldn't serve any purpose there. Such layout
objects are "owned" the new PaginationState class, and destroyed when
the pagination layout fragment tree is no longer needed.
The page area serves as a boundary between the document's contents and
the (non-DOM) page boxes. Therefore, don't propagate info from a page
area fragment to its parent (page border box) fragment. They will
eventually exist in different coordinate systems. OutOfFlowLayoutPart
needs to be updated because of this. Out-of-flow layout needs to take
place when we have returned to the root algorithm. OutOfFlowLayoutPart
now needs to grab any pending OOFs manually from each fragmentainer
(page area inside page border box inside page container), and lay them
out.
No behavior changes intended, unless PageMarginBoxes are enabled.
Keep on reading. We're almost done.
When PageMarginBoxes are enabled, any @page properties that are to apply
in a page context according to the spec may now have paint effects.
@page borders for instance. Add a test for that. Note that layout still
doesn't position the page area correctly within the page border box,
which is why the text in the test is centered (if it were positioned at
0,0, it would have been painted over the border). StyleResolver needs to
be adjusted, to make sure that initial style is returned if the page
context is inside a display:none subtree (an existing test would fail if
not). If computed style is to be generated, on the other hand, make sure
that it becomes display:block.
Bug: 40286153
Change-Id: I59b088bcdde3d95782358809f2377cd61e6a1f73
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5453623
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1292911}
--
wpt-commits: 78d3bcd3bbe1d6989d4abed6b038546e07091520
wpt-pr: 45736
Automatic update from web-platform-tests
webnn: add IDL and mojo definition of gelu operator
This CL also adds validation tests in WPTs and a unit test
`WebNNGraphImplTest.GeluTest`.
Bug: 40206287
Change-Id: Ia197fa637e036e73c4e7d5e832685364633c0384
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5470161
Commit-Queue: Shiyi Zou <shiyi.zou@intel.com>
Reviewed-by: Alex Gough <ajgo@chromium.org>
Reviewed-by: ningxin hu <ningxin.hu@intel.com>
Auto-Submit: Shiyi Zou <shiyi.zou@intel.com>
Reviewed-by: Austin Sullivan <asully@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1292836}
--
wpt-commits: 4e4122e584b52d65fdb20b109ab72703dcca070f
wpt-pr: 45817
Automatic update from web-platform-tests
[aspect-ratio] Fix webm file that caused test flakiness
Test that uses this webm file started flaking when the file was changed
last month in
8bfc72a4f7
The linked chrome bug says the test is flaky on mac and fails on linux,
but flakiness dashboard shows it is actually flaky on all platforms on
the bots. See go/offqr
The test consistently fails on my local mac.
Simply re-encoding[1] the video with the vp9 version on my machine[2]
makes the test pass on chrome and doesn't regress on safari or firefox.
So give the re-encoded video a try?
The content of the video is not relevant to the test anyway, only the
dimensions of the video are relevant.
[1] ffmpeg -i support/2x2-green.webm -vf scale=iw*1:ih*1:flags=neighbor -c:v libvpx-vp9 -preset slow -crf 18 output.webm
[2] Lavc60.31.102 libvpx-vp9 instead of Lavc60.3.100 libvpx-vp9
Fixed: 333058973
Change-Id: If5f488b1bd4cbc16fec669dda682b8c2be97abfc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5492281
Auto-Submit: David Grogan <dgrogan@chromium.org>
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1292740}
--
wpt-commits: 514826504bc76f0d063d8758437b4c6e49b2785b
wpt-pr: 45920
