This renames the pref to remove 'experimental' and turns it on by default.
For integration with the CC, any DOM objects that are the target of a WeakRef or registered with a FinalizationRegistry have their wrappers preserved. WeakRef.deref() checks whether any wrapper is still preserved and returns undefined if not, to avoid giving out references to wrappers whose DOM object has been cycle collected.
Tests exercising browser integration are under js/xpconnect/tests/mochitest/.
Differential Revision: https://phabricator.services.mozilla.com/D77656
These are based on the some of the engines we have in the tree already, but grouped into one main test checking the parameters are processed correctly.
This provides a base set of tests, that covers some previous bugs, and ensures the parameters get set on the engines correctly. There are other tests to ensure the integration of engines with the UI etc, hence it is not needed to do full integration tests with OpenSearch engines.
Differential Revision: https://phabricator.services.mozilla.com/D78530
This patch is a workaround for an issue that causes an intermittent failure
in test_trr_case_sensitivity.js.
I was able to reproduce the bug locally with some logging, but not with
nsHttp:5 or under rr, which made it difficult to diagnose the root cause.
What I was able to determine using logging and timestamps in the nodejs code
is that we would not get the "end" event for a request, to which we were
reacting to send back the DoH response. The request has a timer, and
eventually that timer would fire and cancel the request. At that point
we would see the "end" event in nodejs but it's too late to actually process
the response.
It's not clear if this was a bug in Firefox's HTTP2 implementation
(maybe the end isn't signaled properly) or in nodejs.
This fix makes it so we send back the response when the number of bytes
specified in contentLength reaches the server.
We should investigate in a follow-up bug if there's another Necko bug
involved here.
Differential Revision: https://phabricator.services.mozilla.com/D78676
This is just cleanup and should have no behavior changes. In the future,
I may optimize GetPrimaryFrame to not flush frames in the whole document
if the style of the node and ancestors haven't changed.
I think one bit of this function shouldn't be needed, but I have left it
as is for now.
Differential Revision: https://phabricator.services.mozilla.com/D78886
Move call_indirect's signature check after pushing the frame. We are going to start to implement trampolines as inline code in call_indirect and so, we will push frame and only then tail call to one of the function entries.
Differential Revision: https://phabricator.services.mozilla.com/D75924
Mozilla consider that we should protect even Nightly testers from the behavior
change of bug 1320229.
And I forgot to modify the new mochitest for bug 1635224 which is a regression
of bug1320229.
Differential Revision: https://phabricator.services.mozilla.com/D78841
Automatic update from web-platform-tests
[ScrollTimeline] Update compositor timeline from blink timeline
Previously CompositorTimeline was updated on Animation level which
introduced a reverse dependency. This patch moves the update logic up
to AnimationTimeline level to fix this issue.
Bug: 921031
Change-Id: Iaaa92686003c741cad424eb9867a0993193c05c5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2225853
Reviewed-by: Majid Valipour <majidvp@chromium.org>
Commit-Queue: Yi Gu <yigu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#774351}
--
wpt-commits: 15536297d85ebc2e9e0235fa69a6e7d4bec93231
wpt-pr: 23920
Differential Revision: https://phabricator.services.mozilla.com/D78796
Automatic update from web-platform-tests
Remove MainThreadScrollingReasons::kHasClipRelatedProperty
We no longer need to skip composited scrolling for css clip and
clip-path since (perhaps) BlinkGenPropertyTrees.
In compositor, when we hit test on a layer with special clip/mask,
we'll still fallback to main thread hit testing/scrolling because only
the main thread knows which area is hit testable. This is achieved by
cc::LayerTreeHostImpl::IsInitialScrollHitTestReliable() returning false.
Bug: 1074395
Change-Id: I91260b063879812ca82928fe783de25c4b6732a3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2225229
Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org>
Reviewed-by: Philip Rogers <pdr@chromium.org>
Reviewed-by: Robert Flack <flackr@chromium.org>
Reviewed-by: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#774232}
--
wpt-commits: 4c2484a55b58a72b74c0b6c55ab0238cf11efb4a
wpt-pr: 23900
Differential Revision: https://phabricator.services.mozilla.com/D78793
Automatic update from web-platform-tests
Fix support for StaticHandler without format_args
--
Support multiple PNGs per reftest comparison
This paves the way for print reftests in which each page will be a
seperate image. At present none of the output formats actually support
multiple images, so we always have to pick a single image to actually
output.
--
Add print-reftest support to the manifest
This adds a new test type to the manifest called print-reftest. Print
reftests are distinguished from normal reftests by filenames
containing -print as the type flag, or by being in directories called
'print'.
--
Vendor pdf.js
This only takes the compiled files necessary for our use case (in
particular build/pdf.js and build/pdf.worker.js from the PDFjs
distribution
--
Add basic print reftest support to marionette executor
Adds support for print reftests, as set out in RFC 41 [1]. This is
based on the WebDriver Print endpoint, using pdf.js to render the
pages of the generated PDF back to PNGs for comparison. The pdf.js
process itself runs in the browser, so there's quite a lot of
back-and-forth traffic involved; this approach is not fast. But we're
unlikely to get too many print reftests, so it's a useful baseline.
https://github.com/web-platform-tests/rfcs/pull/41
--
Add print reftest infrastructure test
--
Support print reftests in Chrome
This uses the underlying CDP command directly since PDF generation
isn't yet supported in Chrome. It also requires the browser to run in
headless mode since PDF generation is only supported in this mode.
--
Move wdspec detection higher in the order of precedence
This is primarilly so that print.py doesn't show up as a print reftest, but
also because wdspec tests are pretty easy to identify unambigously since they're
in a single subtree and are all python files.
--
Rename one WebDriverProtocol class as WdspecProtocol
This naming clash caused a confusing bug; really this class is only for wdspec tests.
--
Fix typo in docstring
Co-authored-by: Stephen McGruer <smcgruer@chromium.org>
--
wpt-commits: 14318a51c8bbb4f93da025d873d0cadcc352f19e, 7f8fed23452026c68eed6d2987eaef13b9a7f561, 13ec04fe7ba89fc2e532c710acb0afbcb4db3715, 96f15e060633d1c2470353acf1e23c31d85897d9, ed440d946653bfbd53eef6cd76314f548bdabeda, 51815349ffae146d3a822a1d9d72046a492709db, c8447fe1835f792d109a019523aca7cdfc6dd72d, b0e3c1ce95151503be5037c2888563f19cc5875e, 7ef00b794ca222b6e59b27997e0bc67c0398a7d6, e06c2c218f9a95d1a18cd175fddd6fe3d3a04d02
wpt-pr: 21901
Differential Revision: https://phabricator.services.mozilla.com/D78788
Automatic update from web-platform-tests
[scroll-timeline] Correctly handle unresolvable cases
For these cases we cannot calculate a meaningful scroll offset:
1. When target is not a descendant of timeline's source.
2. When target has no layout box.
The current draft spec [1] asks for these situations to result into
unresolved scroll offset which keeps timeline inactive.
[1] https://github.com/w3c/csswg-drafts/pull/5124
TEST: wpt/scroll-animations/element-based-offset-unresolved.html
BUG: 1023375
Change-Id: Iec616444dda8dcdd6649e250aa993b439c00885e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2222884
Reviewed-by: Majid Valipour <majidvp@chromium.org>
Reviewed-by: Yi Gu <yigu@chromium.org>
Commit-Queue: Majid Valipour <majidvp@chromium.org>
Cr-Commit-Position: refs/heads/master@{#774144}
--
wpt-commits: 52575c9d7c3139cab33780e114b5cf9237a47157
wpt-pr: 23889
Differential Revision: https://phabricator.services.mozilla.com/D78787
Automatic update from web-platform-tests
Set color-scheme-senstive initial color via cascade
We currently adjust the computed value of 'color' on the document
element to simulate 'canvastext' behavior. However, there's an
incorrect assumption that it's safe to adjust whenever there are no
'color' declarations in the cascade.
During a transition, the base ComputedStyle is the destination style
for the transitioning element, and on the final frame of the
transition, the StyleEngine simply emits a copy of the base style,
without adding any declaration to the cascade. This causes color-
transitions on the document element to "snap back" to black (or white,
depending on color-scheme) when the transition ends.
This CL fixes this by adding an explicit value (CSSInitialColorValue)
which represents this behavior to the cascade. The value is added only
when computing the base style, which prevents incorrect adjustments on
top of the final transition frame.
Bug: 1087188
Change-Id: Ie0d95aaab5b93f1749e461fad0baf41a184f7cb6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2224222
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Reviewed-by: Kevin Ellis <kevers@chromium.org>
Commit-Queue: Anders Hartvoll Ruud <andruud@chromium.org>
Cr-Commit-Position: refs/heads/master@{#774178}
--
wpt-commits: c20b45a0352c65db0ef7f141edfd68d01f1516e2
wpt-pr: 23906
Differential Revision: https://phabricator.services.mozilla.com/D78786
Automatic update from web-platform-tests
[css-grid] Consider 'auto' height items for grid area estimation
We perform a pre-layout, based on a estimation of the grid area, of the
grid items in two different situations: orthogonal and baseline aligned
items.
In the case of baseline aligned items, we were doing this pre-layout
only in the case of items with relative inline and block sizes. However,
items with 'auto' block-size also depend on this estimated grid area
size to properly compute the baseline offset.
It was discarded in the past due to performance concerns, since the
'auto' height is a very common case. However, this codepath is only
executed for baseline aligned items. Since we already applied several
optimization to the baseline alignment logic, I think we can try this
approach to solve the bug and evaluate potential perf regressions when
they appear.
Bug: 1086132
Change-Id: I73c39e6c3ad6cd74aa50fe33106e25cd63b7625f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2215054
Reviewed-by: Manuel Rego <rego@igalia.com>
Reviewed-by: Oriol Brufau <obrufau@igalia.com>
Commit-Queue: Javier Fernandez <jfernandez@igalia.com>
Cr-Commit-Position: refs/heads/master@{#774139}
--
wpt-commits: b4205f9f8b440e56da7fb2bd6cc26643296b02e1
wpt-pr: 23772
Differential Revision: https://phabricator.services.mozilla.com/D78782
Automatic update from web-platform-tests
MathML: check that spacing is not added unless mrow layout is used. (#23916)
This is different from MathML3 which uses "inferred mrow", although
the MathML3 spec is not clear how spacing would be handled anyway and
whether <inferredmrow><mo></inferredmrow> is embellihed.
--
wpt-commits: 6fba8fd9df16c5152392595e6e4f255628b99c74
wpt-pr: 23916
Differential Revision: https://phabricator.services.mozilla.com/D78780
Paul Adenot
Harry Twyford
Simon Fraser
Kunchanapalli Shriram
Chris H-C
Andrea Marchesini
Jon Coppeard
Mark Banner
Valentin Gosu
ssengupta
Kershaw Chang
Emilio Cobos Álvarez
Sebastian Hengst
luma
Dmitry Bezhetskov
Dimi Lee
Julian Descottes
Masayuki Nakano
Razvan Maries
James Graham
moz-wptsync-bot
Yi Gu
Philip Jägenstedt
Xianzhu Wang
autofoolip
Domenic Denicola
Majid Valipour
Anders Hartvoll Ruud
Frédéric Wang
Javier Fernandez