The timeout happens when we get an old element of the 'errorCode'
element in the test code. In this patch, we fix this issue by getting
the element every time we check the condition of the 'errorCode'
condition.
Differential Revision: https://phabricator.services.mozilla.com/D80214
This also fixes a hang in Puppeteer's DOMWorld.js when resolving
the current executionContext promise. With the extra event all
the Puppeteer internal contexts for the tab target have been destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D79450
Similar to the previous patch, this patch moves the last `else` block of
the loops in `WSRunScanner::InitializeRangeStart()` and
`WSRunScanner::InitializeRangeEnd()` to before the text node handling case.
This makes that clearer that the loops are continued only when text node
has no text or only white-spaces.
Depends on D79969
Differential Revision: https://phabricator.services.mozilla.com/D79970
Their topmost `else` blocks mean there is no visible content before/after the
point. In this case, the initialization is simpler. So, they should be
handled first, and make the other blocks outdented.
Depends on D79966
Differential Revision: https://phabricator.services.mozilla.com/D79969
Prepare ffmpeg decoding module to X11 dmabuf implementation. In order to cover both X11 and Wayland backend do:
- Use DMABUFSurfaceImage instead of WaylandDMABUFSurfaceImage
- Use DMABufSurface instead of WaylandDMABufSurface
- Rename former DMABufSurface to DMABufSurfaceWrapper to state it actually wraps the DMABufSurface.
- Use DMABufSurfaceYUV instead of WaylandDMABufSurfaceNV12
Differential Revision: https://phabricator.services.mozilla.com/D79638
We have a clang-plugin check that wants to prefer `SprintfLiteral` over `snprintf`, but for some reason this wasn't caught before clang-11. I _think_ it has to do with previous versions not being able to see that `buflen` was constant, but I'm not really sure.
Differential Revision: https://phabricator.services.mozilla.com/D80021
The top end of the scrollbar seems off by a subpixel amount. Some initial
investigation is documented in bug 1646527 and points to a WR internal bug.
Depends on D80089
Differential Revision: https://phabricator.services.mozilla.com/D80090
I looked at the assertion stacks and checked that there were no new kinds of
assertions being triggered, just more of the same old assertions. Seems
reasonable that as the desktop behaviour moves closer to mobile (by turning
on visual viewport codepaths) the assertion count will also match that of
mobile.
Depends on D80088
Differential Revision: https://phabricator.services.mozilla.com/D80089
This fixes a number of scroll-anchoring WPT tests that otherwise fail with the
final patch in this patchset. This patch also fixes a pre-existing failure on
Android, so we remove the corresponding failure annotation here. The guard
being added already exists on some of the codepaths leading to this function,
and is used to short-circuit other bits of code. However, there are still some
codepaths that end up in this function with a zero display size, and it's better
to leave the visual viewport unset in the presShell than to set it to a zero
size.
Depends on D80086
Differential Revision: https://phabricator.services.mozilla.com/D80087
There's a lot of documents that get created (about:blank and friends) and this
makes it easier to figure out which MVM we actually care about.
Differential Revision: https://phabricator.services.mozilla.com/D80085
Starting in clang-11 we'll get:
`error: variable 'i' is uninitialized when passed as a const reference argument here [-Werror,-Wuninitialized-const-reference]`
Differential Revision: https://phabricator.services.mozilla.com/D79906
There's no need to put this in nsLayoutUtils since it's so closely bound
to presShell anyway. So we move it from being a static nsLayoutUtils function
that takes a PresShell pointer, to being a method on the PresShell itself.
Two functional changes here:
1. Don't run the MaybeReflowForInflationScreenSizeChange code unless the
visual viewport actually changes
2. Run the MaybeReflowForInflationScreenSizeChange if the visual viewport
is reset.
These functional changes can be logically thought of as "group the font-
inflation reflow stuff together with the other visual-viewport-triggered
reflow stuff".
Depends on D80040
Differential Revision: https://phabricator.services.mozilla.com/D80041
There are two parts here. One is the "backstop" in the scrollframe's
ReflowFinished callback, that recomputes the visual viewport size if layout
scrollbars are being used in the root scrollframe. This ensures that the
visual viewport gets resized properly after a reflow, possibly at the expense
of a second reflow to reposition fixed-pos items.
There is also an update to the visual viewport during the reflow itself, after
we have reflowed the in-flow contents (including the root scrollframe) but
before we reflow the fixed-pos items. This allows us to avoid the second reflow
by using the new visual viewport for positioning the fixed-pos items correctly.
This early reflow also skips marking things for a second reflow.
This patch fixes a problem described in bug 1644271 comment 2, among other
things. Specifically, it ensures that when the scrollbar properties (e.g.
maxpos, minpos) are computed, they are computed using an up-to-date visual
viewport size. The up-to-date visual viewport size correctly excludes the space
taken up by non-overlay scrollbars, which wasn't happening without this patch.
Depends on D80039
Differential Revision: https://phabricator.services.mozilla.com/D80040
mLastPos is supposed to be updated by querying the visual viewport offset from
the presShell. However because of the way the visual viewport offset is updated,
this doesn't return a nonzero value until after APZ sends back a repaint request.
So this patch modifies the query to also check if there's any pending visual
viewport offset update being sent from the main thread, and use that. It also
modifies the scroll restoration code to request a properly clamped visual
scroll offset, so that the value stored as "pending" is not just the unclamped
restore destination.
Depends on D80038
Differential Revision: https://phabricator.services.mozilla.com/D80039
The existing comment in BrowserChild::RecvUpdateDimensions may have been
accurate at some point in the past, but I'm seeing cases where setting
the content viewer size itself triggers a reflow. Since the widget size
hasn't been updated yet, the reflow uses some stale values and produces
incorrect outcomes. This patch ensures both the content viewer and widget
get their sizes updated first, and only then do we do the reflow.
Differential Revision: https://phabricator.services.mozilla.com/D79885
Farooq AR
Jonathan Kew
Mathieu Leplatre
Simon Giesecke
Tim Huang
Zhao Jiazhong
Andrea Marchesini
Henrik Skupin
Csoregi Natalia
Zibi Braniecki
Masayuki Nakano
Denis Palmeiro
longsonr
Olli Pettay
Razvan Maries
Martin Stransky
David Major
John Paul Adrian Glaubitz
Kartikaya Gupta
Cosmin Sabou
Kagami Sascha Rosylight
Tooru Fujisawa
Sylvestre Ledru
Timothy Nikkel