Automatic update from web-platform-tests
[Web Payment] Very long instrumentId string test.
This patch adds a test for JSON serialization of a very long string
being passed into PaymentRequest API.
Bug: 1110324, 1115091
Change-Id: Ia6690b2f41ff99190afed4431854515b167056b2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2348411
Commit-Queue: Rouslan Solomakhin <rouslan@chromium.org>
Reviewed-by: Nick Burris <nburris@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#797165}
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2359155
Cr-Commit-Position: refs/heads/master@{#803617}
--
wpt-commits: a7831be8db72dd936070f2c221a7f9f3c5a0c73b
wpt-pr: 25338
All of these reftests end up using a minimum scale with layout/classic scrollbars. (They hit the assert from the patch in bug 1663534.)
Some of them are only written with overlay scrollbars in mind (for example overflow-hidden-region-with-negative-left-positioned-element.html which I looked at in detail).
The change that causes them to fail is the code in nsHTMLScrollFrame::TryLayout that decides if we need scrollbars. Before desktop zooming scrollbars we compared the visual viewport size and the scrolled rect size. With desktop zooming scrollbars we compare the (layout) scrollport and the scrolled rect to determine if we need regular scrollbars and then compare the visual viewport size to the (layout) scrollport to determine if we need scrollbars to scroll the visual viewport inside the scrollport. Then can get different results.
Differential Revision: https://phabricator.services.mozilla.com/D89407
In order to fix bug 1657822 we need to run some reftests with the pref ui.useOverlayScrollbars. This preference doesn't have a default value (it is not set by anything on desktop, it appears only in mobile/android/app/mobile.js and when we set the pref for some mochitests, the look and feel code looks at this pref, which is how we almost (?) always query for overlay scrollbars.). The reftest harness doesn't currently handle this because it gets the current value first and doesn't expect the pref to not exist.
Differential Revision: https://phabricator.services.mozilla.com/D89399
If we need to snap we just don't use the desktop zooming scrollbar path.
A quick look into the scroll snapping code looks like it uses layout only aware things. This should be good enough for now, we can look into supporting scroll snap + pinch zoom later if we need to.
Differential Revision: https://phabricator.services.mozilla.com/D89400
sendKey uses our new relative scroll path that does the scroll by the apz. But we don't have any scroll event ordering expectations when apz is doing the scroll. We trade lossing those expectations for smoother apz scrolling.
So change the test to use a method that doesn't use our new relative apz scroll path and goes back to main thread scrolling.
Differential Revision: https://phabricator.services.mozilla.com/D89402
Not that this is deliberately de-optimizing performance: Now, the HandleError
functions need to use the nsDependentCString constructor to determine the
length of the literals at run-time, since that's lost. While passing that
in addition would reduce the binary size wins again, and is not necessary,
since this code is only called in error situations, which are not
performance-critical.
Differential Revision: https://phabricator.services.mozilla.com/D89148
This requires using the same Element::GetScrollFrame logic used in the new
Element::HasVisibleScrollbars method. This also makes GetScrollFrame public,
so that InspectorUtils can use it.
Differential Revision: https://phabricator.services.mozilla.com/D88505
We don't know why we see initialization failures in the telemetry which
makes it hard to investigate why users aren't getting WebRender and
instead fallback to basic. Let's expose the detailed error message
WebRender already generates and puts in the critical log.
Differential Revision: https://phabricator.services.mozilla.com/D89185
The profiler should guarantee that TLS initializations are done only once (from `profiler_init()`), so there is no need to potentially do it at every TLS access.
Instead, the initialization functions set the TLS states once (to `Initialized` or `Unavailable`, depending on the underlying TLS initialization success), and later accesses to this effectively-read-only flag can be done without thread synchronization.
This reduces the generated code size.
There are also DEBUG-build checks that no accesses are done before initialization; this is theoretically racy, but it's only used to detect too-early accesses in DEBUG builds, which should never happen anyway.
Differential Revision: https://phabricator.services.mozilla.com/D89338
It's never set to anything other than the default, so we can hardwire it as a
constant.
`GlyphCache::max_bytes_used` is also removed.
Depends on D89101
Differential Revision: https://phabricator.services.mozilla.com/D89102
It has a single impl, `GpuProfileTag`, so it's unnecessary generalisation.
This also removes type parameter from `GpuTimer`, `GpuSampler`,
`GpuFrameProfile`, and `GpuProfiler`.
Depends on D89099
Differential Revision: https://phabricator.services.mozilla.com/D89100
When generating a hang report we need to force a hung child process to return
its annotation via the pipe that connects it to the main process. Since the
child is not responding to regular IPC messages we force it to using
platform-specific code:
* On Windows we launch a new thread using CreateRemoteThread() that will
invoke the code used to send the crash annotations. The Windows-specific
code also has another slight modification: it stored the pipe used to send
the annotations in Breakpad's minidump callback context. This patch moves it
into the `gChildCrashAnnotationReportFd` global which is what all the other
platforms use.
* On Linux/macOS we use a signal handler for the SIGTERM signal. It would be
simpler to use SIGUSR1 or another signal that doesn't have special meanings,
but those are all already in use in Gecko (either by jprof or the gcov
machinery). We don't install SIGTERM handlers for anything else but
obvioulsy its semantics get in the way since it's used to politely kill a
process, and Chromium IPC also uses it for that purpose. So to tell apart
our use of SIGTERM from a "regular" terminating SIGTERM we send a magic
value along using sigqueue(). Our signal handler will look for it and only
send annotations when it is set. If the magic number isn't there it will
re-install the default SIGTERM handler and raise the signal once more which
will lead to the process being terminated as it should be.
The patch refactors some of the code so that the PIDs and process/file handles
use platform-independent types to cut down on the amount of duplication we
have there.
Differential Revision: https://phabricator.services.mozilla.com/D87759
This moves the special cases to the printing platform code instead
(where it belongs).
The SupportsMonochrome() implementation is the only thing that I found
to work for the "Microsoft Print to PDF" driver, but other similar
drivers like XPS still claim to support monochrome (even though it's not
true). This should avoid the UI getting in a bad state as described in
the bug though, so may be better?
Depends on D89306
Differential Revision: https://phabricator.services.mozilla.com/D89312
There is a race condition in the "WebDriver:SwitchToWindow" command
that would throw an UnknownError instead of NoSuchWindowError when
the window gets closed at the same time as the command gets called.
Differential Revision: https://phabricator.services.mozilla.com/D89377
A session is defined as string in CDP but target specific commands
and events currently return a number based on the last used index.
This also makes it very easy to discover active sessions.
Differential Revision: https://phabricator.services.mozilla.com/D89352