Automatic update from web-platform-tests
Split testing CSS transitions before load vs. load event behavior when changing <img>.src
The test css/css-transitions/before-load-001.html relies on loading an image where the load is set to 100 seconds such that the window `load` event dispatch is delayed until a CSS Transition is ran. At that point, the image's source is set to the empty string to stop the image load and have the window `load` event dispatched.
Safari has an issue where an <img> pointing to a long-loading resource will continue delaying dispatch of the `load` event on the window even when the image source has been reset. This issue is tracked by https://bugs.webkit.org/show_bug.cgi?id=241676.
As a result, css/css-transitions/before-load-001.html causes a harness timeout in Safari even though the ability to run a CSS Transition before the window `load` event has been dispatched works correctly and the test assertions pass.
We work around that issue by lowering the load duration for the image to 1 second instead of 100. This doesn't changed the functionality that this test is explicitly testing. And to explicitly test that resetting a long-loading image source no longer delays the dispatch of the window `load` event, a new dedicated test is added, which will itself cause a timeout in Safari, but that is what is expected.
Addresses https://github.com/web-platform-tests/wpt/issues/34444.
--
wpt-commits: 644aba8746b83668d5d9033cda16ae3f8bba0b3d
wpt-pr: 34463
Automatic update from web-platform-tests
Fix streaming upload tests
- Streaming upload is disabled on HTTP/1.1. Move some tests to the
h2 file.
- Explicitly test that streaming upload is blocked on HTTP/1.1.
421 handling hasn't been implemented yet.
Also fix the implementation which blocked CORS requests unintentionally.
Change-Id: I8da8ea411ae6d55e2d7dfddc34f3da529651aa7f
Bug: 1234368
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3699531
Commit-Queue: Yutaka Hirano <yhirano@chromium.org>
Reviewed-by: Yoichi Osato <yoichio@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1014859}
--
wpt-commits: d387101095115f28446dbf2da77fb64dea697815
wpt-pr: 34418
Automatic update from web-platform-tests
Split long COOP WPTs.
Following
https://chromium-review.googlesource.com/c/chromium/src/+/3691847
Some COOP WPTs are getting close to timeout on Firefox runners. Split
them further.
Bug: 1318373
Change-Id: If97208b68054f1cf8fb98eff785b5d9300b32c68
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3702340
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Commit-Queue: Arthur Hemery <ahemery@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1013864}
--
wpt-commits: 54614bf4a5b93eb692ea83ebb8743263d038a7d5
wpt-pr: 34461
Automatic update from web-platform-tests
Remove unused function in COOP WPT's common.js (#34390)
A number of tests now use iframe-test.js and we can remove the dedicated
function from common.js, as well as the iframe page.
Bug: 1318373
Change-Id: I051fef673a9d0144ad9e8c90b57f651e27f5edc9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3700015
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Commit-Queue: Arthur Hemery <ahemery@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1013853}
Co-authored-by: Arthur Hemery <ahemery@chromium.org>
--
wpt-commits: aa7c965f8833acc44ce01cc53bc2131b73a72202
wpt-pr: 34390
Automatic update from web-platform-tests
Refactoring iframe coop tests. (#34386)
Iframe COOP tests run using convoluted postMessage and broadcastChannel
messaging. Converting them to use dispatcher.js makes things more
straightforward and contained.
A few notes:
- This is roughly equivalent to https://chromium-review.googlesource.com/c/chromium/src/+/3593078, but for tests using
iframes.
- Combining COOP: same-origin and a cross-origin iframe leads to
a noopener behavior. Behaviors are now tested more precisely, and distinguish between noopener and regular COOP opening.
- We're also verifying multiple ways of creating popups and making sure they all match. Previously we tested window.open, anchors, and GET and POST forms. We've removed POST forms that are not compatible with WPT pipes, and exerce the same path as GET forms.
This enables the followup:
https://chromium-review.googlesource.com/c/chromium/src/+/3700015
Bug: 1318373
Change-Id: I1ba7459c9ba3a08f548e132a51cff3369bd98da3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3691847
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Commit-Queue: Arthur Hemery <ahemery@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1013604}
Co-authored-by: Arthur Hemery <ahemery@chromium.org>
--
wpt-commits: 84ea5cbb864973fd3672d01d07fd6f740b94e915
wpt-pr: 34386
Now that all frames store the caller's frame pointer, we can add it to `CommonFrameLayout`
and get rid of `FramePointerOffset`.
This also removes `JitFrameLayout::unused_`. This has to happen at the same time so that
`sizeof(JitFrameLayout)` doesn't change (a lot of code depends on that for alignment).
`JitFrameLayout` is now aligned on the frame pointer instead of the return address.
This lets us simplify some of the Wasm stubs code (especially for ARM64) where we had
to workaround the old aligned-after-return-address invariant.
Differential Revision: https://phabricator.services.mozilla.com/D149760
This renames the `numActualArgs_` field to `unused_` and stores a constant there
for now. The next patch will remove this field and simultaneously add the frame
pointer to `CommonFrameLayout`, preserving the current `JitFrameLayout` size.
Differential Revision: https://phabricator.services.mozilla.com/D149759
Pending further changes iff we want to do them (like comment 5), this is the
right thing to do.
I'm not a fan of comment 5 since in the past I've been bitten by Wayland
compositors not comparing stuff case-insensitively, so making everything
lowercase is probably simpler.
Differential Revision: https://phabricator.services.mozilla.com/D149911
I could reproduce the intermittent locally and when it occurs, the initial editor actually didn't have focus.
I think that what happens is that we hit a race condition where the focus is stolen by the initial editor after we clicked on a new stylesheet
and switched to a new editor.
Differential Revision: https://phabricator.services.mozilla.com/D149952
be -> 40903e59f57663eadf4ed9cf490324dd69622d55
el -> b185ae1f46deb67ad3f6d34580c79de76a8b871a
en-GB -> 9a448c4f443621b517a7c4d33a8fba602fc41b8e
fi -> c78403643c186593efd570a3aba5d06a9c8073a9
ia -> 233a08d3c873528c0a34888bb92423bfb44a9cfd
is -> 408ba9e6683105dc0093880596bc70f37deaef7c
pt-BR -> 92a05d273ac48c0c50ad1f69a9df23875e56dd48
pt-PT -> 7802fd0491ba759cf1465d3d7851746b3e960112
uk -> 3052e29904199fc82ec1ca85cba8502eb400668e
Actually, GeckoView registers both desktop and mobile actor for `<select>`
element. It is unnecessary to use desktop's `<select>` actor.
But, if GeckoView doesn't register desktop's `<select>` actor,
`layout/forms/test/test_select_reframe.html` will be failure since GV doesn't
handle `mozhidedropdown` that is a event when the control is unbinded from
layout tree.
So we need to handle this for this situation that is one of dismissed cases.
Differential Revision: https://phabricator.services.mozilla.com/D149526
gcc -std=c++20 (but not clang -std=c++20) complains about template class definitions that specify the template parameter on the class constructor.
In file included from /builds/worker/workspace/obj-build/dist/include/nsDisplayList.h:43,
from /builds/worker/workspace/obj-build/dist/include/mozilla/layout/RemoteLayerTreeOwner.h:17,
from /builds/worker/workspace/obj-build/dist/include/mozilla/dom/BrowserParent.h:23,
from /builds/worker/checkouts/gecko/accessible/ipc/other/RemoteAccessible.cpp:13:
/builds/worker/workspace/obj-build/dist/include/mozilla/layers/BSPTree.h:30:18: error: expected ')' before '*' token
| BSPPolygon<T>(T* aData, gfx::Polygon&& aGeometry)
| ~ ^
Differential Revision: https://phabricator.services.mozilla.com/D149813
For `--backgroundtask ... --jsdebugger` invocations, the devtools
profile is kept inside the ephemeral background profile. This means
that breakpoints, etc are not preserved across repeated debugging
invocations. This change eases the debugging process.
Differential Revision: https://phabricator.services.mozilla.com/D145893
The preceding call of `InsertBRElement` may collapse selection at the inserted
padding `<br>` element. Only when calling `HandleInsertParagraphInParagraph`,
`InsertParagraphSeparatorAsSubAction` uses `Selection`. So, only in this case,
we need to recompute the point to split for keeping current (odd) behavior.
Note that in normal cases, using `atStartOfSelection` gets same result.
However, if there are some invisible nodes such as comment nodes, doing it
may change the behavior. For now, we should keep the current behavior. It
should be sorted out when we make it stop inserting `<br>` elements for the
preparation of split without checking whether it's actually necessary.
Differential Revision: https://phabricator.services.mozilla.com/D149101
The expectations are exactly same as Chrome's behavior. And checked by my
hands briefly, Safari also behaves as same as Chrome.
Differential Revision: https://phabricator.services.mozilla.com/D149100
It touches `Selection` redundantly (i.e., immediately after that, it or its
caller collapse `Selection`). So we can just stop it because we can ignore
the cases when the handling fails after the redundant `Selection` update and
it can be caused by tricky things with the mutation event listeners.
Note that without changing `SplitNodeResult` a lot, we cannot make it return
`SplitNodeResult`, and currently there is no motivation to do it because the
only caller does not need the detail of the split. Therefore, I give up doing
it.
Differential Revision: https://phabricator.services.mozilla.com/D149099
In Linux TV test, as thare is case that the input filed lost the focus until
showing popup, timeout failure happens since the expected poup never be shown.
To avoid this, if losing the focus, retry setup to open popup.
Differential Revision: https://phabricator.services.mozilla.com/D149713
I tried to make the latter half preparation to call
`HTMLEditor::SplitParagraphWithTransaction`, but I cannot make it cleaner
because it needs to return `HTMLBRElement*` and `EditorDOMPoint` with maybe
modifying the DOM tree. So, I keep it as-is, but I make replace the unnecessary
duplicated `EditorDOMPoint` with the original one which is adjusted to avoid
to create new empty link in the right paragraph.
Differential Revision: https://phabricator.services.mozilla.com/D149096
Using the wide scope `EditorDOMPoint pointToInsertBR` makes it harder to read.
Although this duplicates a call of `HTMLEditor::InsertBRElement` and a couple of
post processing, but I think that it's easier to read/understand.
Differential Revision: https://phabricator.services.mozilla.com/D149094
moz_inputhistory can accept empty string as its input column.
WHERE Clause of SQL getting Adaptive History has
`:searchString BETWEEN i.input AND i.input || X'FFFF'`
condition, but it will be true even if the input is empty string.
This is the cause of this bug.
So, we add one more condition checking whether the input is empty string to
resolve this problem.
Differential Revision: https://phabricator.services.mozilla.com/D149933
If it needs to insert a `<br>` but the editor does not want to create new
paragraph, its caller should be default to insert a `<br>` element. Rather
than checking this at inserting `<br>` element, it should do it at considering
the place to insert the new `<br>`.
Differential Revision: https://phabricator.services.mozilla.com/D149093
Antoine Quint
moz-wptsync-bot
Yutaka Hirano
Arthur Hemery
Blink WPT Bot
Michael Ratcliffe
Neil Deakin
Masayuki Nakano
Jan de Mooij
Jan Horak
Emilio Cobos Álvarez
Tooru Fujisawa
Julian Descottes
Alexandre Poirot
manekenpix
Mozilla Releng Treescript
Mark Banner
Makoto Kato
Chris Peterson
Nick Alexander
criss
Thomas Wisniewski
Hiroyuki Ikezoe
Andreea Pavel
Daisuke Akatsuka