Some pages use this to hide the focus outline. On Blink it seems black,
WebKit uses it to expose the OS accent color. Make it black, which is
the default when the color isn't implemented on a given platform.
Differential Revision: https://phabricator.services.mozilla.com/D119036
As those don't have the same incremental reflow issues as root paginated
documents, and we do need this for remote iframes to update their
viewport.
Differential Revision: https://phabricator.services.mozilla.com/D119104
As those don't have the same incremental reflow issues as root paginated
documents, and we do need this for remote iframes to update their
viewport.
Differential Revision: https://phabricator.services.mozilla.com/D119104
This avoid the weirdness where we reach into the binary message data to
get the message type and then unconditionally deserialize as JSON anyway.
Differential Revision: https://phabricator.services.mozilla.com/D118452
The previous function used early return in a way that made it hard to
follow, and made undocumented assumptions about the minimum possible
size of a message. This version is intended to have clearer control
flow and make the assumptions more explicit.
Differential Revision: https://phabricator.services.mozilla.com/D118146
Going forward, all jobs will be running on WebRender platform variants
so we don't really need this check anymore. This fixes a regression from
bug 1717825.
Differential Revision: https://phabricator.services.mozilla.com/D119273
selectAudioOutput() grants are per-device, but getUserMedia() grants expose all
speakers associated with any microphone.
When exposed, speaker devices have labels even when there is no active capture device.
Differential Revision: https://phabricator.services.mozilla.com/D118443
These are enough for me to run bootstrap+configure+build.
Some touch third-party code (gyp), but per discussion in the earlier
versions of this revision that seems fine.
Differential Revision: https://phabricator.services.mozilla.com/D119080
Sometimes generating a crash dump takes long enough that the harness can have timed out
before the parent process has exited, so we record the result as a timeout rather than
a crash.
Differential Revision: https://phabricator.services.mozilla.com/D118722
This patch launches content processes with the `MOZ_HEADLESS` env var set
if they're using GTK with an X11 display (and there's no other reason
they'd need GTK).
The goal is to avoid exhausting Xorg's default limit of 256 clients if
there are many content processes due to Fission. If these conditions
are met, the content process doesn't need to eagerly connect to the X
server. This does not affect the sandbox policy, and content processes
can still use X if needed for, e.g., WebGL.
The boolean pref `dom.ipc.avoid-gtk`, set by default, controls this
feature. In the future it could also be extended to minimize GTK use
with Wayland displays.
Note that disabling `widget.non-native-theme.enabled`, which is also
enabled by default, will restore the use of X11 in all content processes
even if this pref is set; the alternative is that widgets wouldn't render
in that case.
This change will also save some memory for now-unnecessary instances of
GTK's global state, and improve content process startup time.
Remove also the temp pref dom.ipc.remote-mozIcon because it cannot work
anymore with the content process being headless.
Differential Revision: https://phabricator.services.mozilla.com/D112197
In most cases, it's called with selection range which is collapsed in a text
node, but otherwise, the selection may be in an element which cannot have
text nodes. Therefore, before handling the insertion, it should look for
ancestor element which can have text nodes.
Note that this patch makes inserting text immediately before an inclusive
ancestor element whose parent can have a text node. However, both Blink and
WebKit ignores if there are invisible/empty inline nodes. So, even with
this patch, Gecko keeps failing in some tests of the WPT. It should be handled
in a follow up bug because doing it requires complicated code.
Differential Revision: https://phabricator.services.mozilla.com/D119065
These are enough for me to run bootstrap+configure+build.
Some touch third-party code (gyp), but per discussion in the earlier
versions of this revision that seems fine.
Differential Revision: https://phabricator.services.mozilla.com/D119080
Automatic update from web-platform-tests
[wpt] Fix grid-item (no) aspect-ratio tests.
Renaming scheme got lost, however basically:
grid-item-no-aspect-ratio-stretch-4.html -> grid-item-aspect-ratio-stretch-1.html
grid-item-no-aspect-ratio-stretch-5.html -> grid-item-aspect-ratio-stretch-2.html
grid-item-no-aspect-ratio-stretch-6.html -> grid-item-aspect-ratio-stretch-3.html
grid-item-no-aspect-ratio-stretch-7.html -> grid-item-aspect-ratio-stretch-4.html
These tests all had a viewBox defining a valid aspect-ratio. Due to:
https://github.com/w3c/csswg-drafts/issues/6286#issuecomment-866986544
These tests *should* have an aspect-ratio, and when stretched in one
dimension, should reflect to the other dimension (if unconstrained). See:
https://github.com/w3c/csswg-drafts/issues/5713#issuecomment-755791551
The below two tests basically just got renamed:
grid-item-no-aspect-ratio-stretch-8.html -> grid-item-no-aspect-ratio-stretch-4.html
grid-item-no-aspect-ratio-stretch-9.html -> grid-item-no-aspect-ratio-stretch-5.html
grid-item-no-aspect-ratio-stretch-10.html -> grid-item-no-aspect-ratio-stretch-6.html
But tests updated to correctly assert that the natural size would still
be respected.
To all these test-cases I also added "grid-template: 100% / 100%;" as
there is further complexity when inside an auto row/column which is
tested elsewhere.
(Transferred minimum size for replaced elements with an aspect-ratio).
Bug: 1114013
Change-Id: I062f67e291cc62fa63a53370595780dae16abf3b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3003564
Reviewed-by: David Grogan <dgrogan@chromium.org>
Reviewed-by: Kurt Catti-Schmidt <kschmi@microsoft.com>
Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#898351}
--
wpt-commits: ec4e2eecc6a5bd2f21c81dbe03862c2cdf17cf8c
wpt-pr: 29567
Automatic update from web-platform-tests
[GridNG] Placement of grid items with a negative margins
Previously, in |ContributionSizeForGridItem| margins were clamped to
zero before adding them to the contribution. Therefore, grid items with
negative margins were not being placed correctly. In this CL, the order
of operations is flipped: add the margin to the contribution and the
result is then clamped to zero.
Bug: 1045599, 1225424
Change-Id: I6fc2726d4744d520430b2ca96b3509a396d73538
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3002394
Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org>
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#898232}
--
wpt-commits: 396d58256124dcb6f81105846e0ac96a93132c73
wpt-pr: 29564
Automatic update from web-platform-tests
Handle z_at_xy_zero being very large.
When z_at_xy_zero starts off very large, subtracting z_delta from it
might still leave it larger than kInfiniteCoordinate, so we can't assume
that it is smaller. Just forcing it to be smaller should be good enough
given how much of an edge case this is. (We won't get sensible results
anyway, since the inaccuracy of floating point will have made them
wildly inaccurate already.)
Fixed: 1224066
Change-Id: I77b6ad4e1569664094cb2ba7c0e17135fe0cae48
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3002328
Reviewed-by: Robert Flack <flackr@chromium.org>
Commit-Queue: David Baron <dbaron@chromium.org>
Cr-Commit-Position: refs/heads/master@{#898176}
--
wpt-commits: cc1a792689fa15026f7b0c85b1d8df715c813389
wpt-pr: 29562
Automatic update from web-platform-tests
Keep points on edges crossing w=0 under kInfiniteCoordinate.
This adds half of std::numeric_limits<float>::epsilon() (FLT_EPSILON),
which is the smallest representable difference for a float at 1.0, so
that the code to shift t away from the point where w=0 will move it
enough so that the result is less than kInfiniteCoordinate.
Bug: 1224066
Change-Id: I7df134c277f280987405d0d0c2d47de15d3ef55d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3002270
Reviewed-by: Robert Flack <flackr@chromium.org>
Commit-Queue: David Baron <dbaron@chromium.org>
Cr-Commit-Position: refs/heads/master@{#898172}
--
wpt-commits: 428213381f43418226b8df335710c8e8c74d10ee
wpt-pr: 29563
Automatic update from web-platform-tests
Fix fragment tree consistency in |ComputeCaptionFragments|
This patch fixes when |ComputeCaptionFragments| runs layout
but discard the results without adding them to the fragment
tree after layout.
The repro case reaches this state from:
ComputeCaptionFragments
NGTableLayoutAlgorithm::ComputeCaptionBlockSize
NGTableNode::ComputeCaptionBlockSize
NGFlexLayoutAlgorithm::ConstructAndAppendFlexItems
NGFlexLayoutAlgorithm::LayoutInternal
NGFlexLayoutAlgorithm::Layout
Bug: 1225014
Change-Id: I99f211fa010d7d861eba059f7742665dfdd38475
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2999661
Reviewed-by: David Grogan <dgrogan@chromium.org>
Commit-Queue: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/master@{#898108}
--
wpt-commits: 92e9e675aef13c9020ae518d9adf1bbb40ab4f9f
wpt-pr: 29556