This feature is enabled only on Nightly, so we have to enable the
prefernece to make sure this test works on beta/release.
Differential Revision: https://phabricator.services.mozilla.com/D131172
* Recommend the Build Tools over the full Community IDE install
* Bump Windows 10 SDK, C++ ATL version
* Remove "Game development with C++" workload, because it doesn't seem
to be required anymore - I'm leaning on review and natural
developer-testing to confirm this assumption.
Differential Revision: https://phabricator.services.mozilla.com/D130773
The expectation of 50% idle stacks was too optimistic, since we cannot control how the OS interacts with idle threads and may still had CPU time to them unexpectedly.
The patch now only expects at least one zero and at least one non-zero.
Having non-zero values should be guaranteed by the work necessary to go around the loop.
Having zero values is still hopeful, in practice we've seen a minimum of 7 out of 20 zeroes, so expecting only one should be much easier to achieve consistently. But in the worst case it could still theoretically fail; If that happens we may need to tweak again, by increasing the loop count, and/or running the whole test a few times.
Differential Revision: https://phabricator.services.mozilla.com/D131099
This is a minimal split to support updating ReadableStream.tee; we will soon
need to hold a reference to the pull algorithm in TeeState.
Differential Revision: https://phabricator.services.mozilla.com/D129320
Unfortunately this is not currently maintained (it's been broken
since the addition of sub_slice compositor surface support).
It's also complicating efforts underway to refactor the way that
picture cache dependencies are handled as part of the visibility
pass refactoring work.
For these reasons, let's remove this functionality. If we find
someone with time to maintain it in future, it's likely that we
could restore most of the viewer code, and update the picture
cache code in WR to output the appropriate information.
Differential Revision: https://phabricator.services.mozilla.com/D131105
Currently we're falling back when hitting an uninitialized filter (e.g. a bad
url) and the fallback path just draws nothing. We can do that just as well by
drawing nothing ourselves.
Differential Revision: https://phabricator.services.mozilla.com/D130281
This patch potentially changes the behavior when the scrolled frame is in
vertical writing-mode, but it should be the correct way to handle the scrollbar
change.
Differential Revision: https://phabricator.services.mozilla.com/D130711
This updates the non-localized strings that appear in the Firefox Suggest
preferences UI with the final approved strings.
Differential Revision: https://phabricator.services.mozilla.com/D131031
LineBreaker::Strictness is just an alias of LineBreakRule in Segmenter.h. This
is to reduce the dependency of the legacy LineBreaker.
Differential Revision: https://phabricator.services.mozilla.com/D131026
LineBreaker::WordBreak is just an alias of WordBreakRule in Segmenter.h. This is
to reduce the dependency of the legacy LineBreaker.
Differential Revision: https://phabricator.services.mozilla.com/D131025
In recent version of espeak-ng/speechd the language field is accurate
and doesn't need to be amended with the variant field.
The variant field seems to be the speaker's name which we don't have an
equivalent field for in the DOM voice object.
On my system speech-dispatcher lists 109 languages and 79 "variants".
It then applies each variant (eg. Denis, Boris, Steph) to each language
resulting in 8,611 voices.
Differential Revision: https://phabricator.services.mozilla.com/D130937
The problem here is a race: Even though the user is enrolled in the online
scenario via Nimbus, the Nimbus urlbar variables may not be initialized by the
time we migrate Suggest preferences on startup. The data-collection pref is set
when we [migrate prefs](https://searchfox.org/mozilla-central/rev/df6434d2ebfdf2b5f89f205fc81d60d64a774fe1/browser/components/urlbar/UrlbarPrefs.jsm#872) -- and only there --
so we're not hitting that path like we should be. That's because the scenario
can still be the default value of "offline".
Fortunately the Nimbus client API gives us a ready promise we can await that is
resolved when the feature is loaded and ready, so all we need to do is await it
before trying to update the scenario and do migrations.
Differential Revision: https://phabricator.services.mozilla.com/D131065
When application/x-moz-file-promise MIME content is adverised, save the file to /tmp/dnd_file-*/ directory and
offer it as text/uri-list MIME type.
Based on patch by Tobias Koenig.
Differential Revision: https://phabricator.services.mozilla.com/D130767
