As cubeb might call audio stream's state callback very soon after we start cubeb, we have to create the promise beforehand in order to handle the case where we immediately get `drained`.
Differential Revision: https://phabricator.services.mozilla.com/D96770
In the change from bug1674597, AudioSinkWrapper only handles the promise when we succeed opening AudioSink. However, it forgots to handle the promise when fail to start AudioSink.
Differential Revision: https://phabricator.services.mozilla.com/D96738
Once we have seen the unload event it's internal state flag
shouldn't be reset if another beforeunload event is received.
Depends on D96758
Differential Revision: https://phabricator.services.mozilla.com/D96760
Most of the deletions here come from bug 1481612, the `--with-windows-wheel` option to `mach vendor python`, which according to that commit message "is very single-purpose: it's intended to let us vendor an unpacked
wheel for psutil on Windows". Since vendoring `psutil` is something we're no longer doing, we can safely just delete that added code.
Differential Revision: https://phabricator.services.mozilla.com/D90919
Install `psutil` when setting up the `mach` `virtualenv`s and stop importing the in-tree version in the build.
Nothing in-tree currently assumes or mandates the installation of `psutil` (all uses of `psutil` are guarded with imports of the form `try : import psutil; except ImportError: psutil = None`), so there's no back-incompatibility concerns here. There will be an awkward period where telemetry will be lacking CPU/disk data for everyone until they re-run `mach bootstrap` or `mach create-mach-environment`, but that will come back as people gradually update their `virtualenv`s.
An alternative to circumvent that issue is REQUIRING that `psutil` be installed by adding an assertion in `mach` that `psutil` can be found (allowing us to remove all the conditional logic in-tree around whether `psutil` is installed), but I wouldn't claim that we're ready to do that and deal with whatever fallout might occur.
Differential Revision: https://phabricator.services.mozilla.com/D90914
The test was not using the correct telemetry archive testing facilities, thus
not properly waiting for pings to be written to disk.
Differential Revision: https://phabricator.services.mozilla.com/D96974
This patch simplifies the slab allocator in various ways, most importantly separating the packing logic and texture cache glue (dealing with swizzling, cache entries, etc.). The former is moved into TextureUnits/TextureUnit and the latter is mostly contained into TextureCache.
This patch should have no functional change. The goal to make it easier to introduce custom slab sizes for glyphs in a followup patch, and later use different packing algorithms.
Differential Revision: https://phabricator.services.mozilla.com/D95869
Also tweak the visualization in various ways so that having a large amount of regions (glyphs) doesn't bring down simple SVG viewing software.
Differential Revision: https://phabricator.services.mozilla.com/D95758
Since glyphs are rarely larger than 128x128, we can reduce the amount of wasted space from partially used glyph regions by having smaller ones (and more of them).
Differential Revision: https://phabricator.services.mozilla.com/D95757
This allows us to avoid instantiating separate gfxFont objects when content is tagged
with different 'lang' attributes, yet ends up using the same fonts (e.g. Wikipedia may
use a default font such as Arial for language names/links that are tagged with several
dozen different languages).
Differential Revision: https://phabricator.services.mozilla.com/D96978
These already-flakey tests seem to get pushed over the edge to "almost always
busted" with more instrumented Rust code. Disabling seems like the right approach
to get more coverage elsewhere (and the other similarly-flakey tests suggest
we're probably still hitting the root cause).
Depends on D95950
Differential Revision: https://phabricator.services.mozilla.com/D96627
Automatic update from web-platform-tests
Move wpt/css/composite-bgcolor-animation to wpt/css/css-backgrounds
The wpt/css/composite-bgcolor-animation was newly added in this CL:
https://chromium-review.googlesource.com/c/chromium/src/+/2464428,
which is specifically to tests the ongoing work of composite background
color animation.
It turns out that we already have wpt/css/css-backgrounds that has
a lot of tests in it to test painting background color. So this CL
moves the tests under composite-bgcolor-animation to css-backgrounds,
and then make the entire css-backgrounds a virtual test suite. This
will ensure more test coverage.
As a result of creating a new virtual test suite, there are 4 tests
currently failing. IMHO that should not block this CL because this
feature is behind a flag.
Bug: 1148305
Change-Id: I3759d0f431d8bcdb5e73f6aec42462ccdb343101
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2533586
Reviewed-by: Kevin Ellis <kevers@chromium.org>
Commit-Queue: Xida Chen <xidachen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#826921}
--
wpt-commits: 8ac9c3e6d5275922760b01889aac6be48b69fbdd
wpt-pr: 26509
Automatic update from web-platform-tests
Only do blending for ::selection background for replaced elements
We did a BlendWithWhite() to not have custom selection backgrounds fully
obscure replaced content like images. But, we also did that blending for
text which means the author could not fully control the ::selection
background. Instead, only do this blending for replaced content. This is
in line with what Firefox does and what the spec says[1].
The blending is still done on the UA default background color for both
text and replaced content in LayoutTheme.
[1] https://drafts.csswg.org/css-pseudo-4/#highlight-replaced
Bug: 1018450
Change-Id: Ibb2c63d549a21706a511bbb47ff4c686b246314b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2532555
Commit-Queue: Rune Lillesveen <futhark@chromium.org>
Reviewed-by: Stephen Chenney <schenney@chromium.org>
Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#826867}
--
wpt-commits: a1b86038015d6f19b3d27c6388ded3409998740b
wpt-pr: 26487
Automatic update from web-platform-tests
[client-hints] Viewport-Width correct value for navigation requests
Currently, Viewport-Width hints send the display width for navigation
requests, rather than the actual viewport width.
This CL fixes that for iframes and for new windows that have the same
viewport as their opener.
Bug: 825892
Change-Id: Ib01f394325ed3753b9a89dbdbcada1db0d3b029c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2494876
Commit-Queue: Yoav Weiss <yoavweiss@chromium.org>
Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Tarun Bansal <tbansal@chromium.org>
Cr-Commit-Position: refs/heads/master@{#826750}
--
wpt-commits: eece9cd203ae5b1ff1702be590e3558e94e3a104
wpt-pr: 26334
