Disabled the following for windows10-aarch64:
- test_getUserMedia_audioCapture
- test_AudioChange_mp4.html
- test_bug1255618.html
- test_singleSourceDest
- test_mediaElementAudioSourceNodeFidelity
- test_maxChannelCount
- test_abort
- test_audio_capture_error
- test_call_start_from_end_handler
- test_recognition_service_error
- test_success_without_recognition_service
- test_ExperimentalAsync
- test_peerConnection_restartIceNoBundle.html
All of these tests tend to fail on the first run of the push, then pass on the retry run.
Differential Revision: https://phabricator.services.mozilla.com/D24569
--HG--
extra : moz-landing-system : lando
This patch renames nsIPresShell::SetPendingVisualScrollUpdate() to
ScrollToVisual(), and adds an instant vs. smooth option.
SetPendingVisualScrollUpdate() still exists, as a helper for the instant case.
Differential Revision: https://phabricator.services.mozilla.com/D24553
--HG--
extra : moz-landing-system : lando
Bug 1534522 added win64-aarch64-eme/opt builds, which are artifact builds
that glue together a win64-aarch64/opt build and a win32/opt build.
This enables EME on the corresponding nightlies in a slightly different
way:
- this adds a no-eme build that corresponds to win64-aarch64/opt.
- this turns the existing nightly into an artifact build that glues
together that no-eme build and the win32 nightly.
The no-eme build cannot have the nightly attribute set, first because
the beetmover transform fails in that case, and because that would imply
shipping those builds, but they're not meant to be shipped this way.
It also has run-on-projects set to an empty list so that it doesn't
appear by default in `mach try fuzzy`, while still being triggered when
needed due to being a dependency of the nightly build.
It is preferable to keep the win64-aarch64{,-eme}/opt builds untouched
to make things easier for try (the win64-aarch64 ones being the main
ones to try; also, the -eme builds currently fail with --artifacts).
Ideally, like in bug 1534522, we'd add a diffoscope build to ensure
the variations between the nightly and its base no-eme build are within
control, but currently, that would trigger nightlies on every push,
which is not desirable. Ideally, they'd trigger whenever both their
dependencies are in the target task graph. We leave that to a followup.
Differential Revision: https://phabricator.services.mozilla.com/D23640
We need to have full symbols uploaded for the upcoming EME-enabled
win64-aarch64 nightlies, and the tasks to do that are derived from the
nightly itself, which is going to be an artifact build. Bug 1527463 took
care of adding the option to enable that, and we turn it on for
EME-enabled builds.
MOZ_ARTIFACT_TASK_WIN32_OPT is not exactly the right thing, but we're
already using it to enable EME in
browser/config/mozconfigs/win64-aarch64/common-opt and is only set on
those builds.
Differential Revision: https://phabricator.services.mozilla.com/D23639
The previous patches didn't take care of the case there might have an asmjs
folder in the older version. To fix that, this patch makes Client allow to have
asmjs folders in the older version by requesting the callee of TypeFromText()
for passing the current storage version. If the version is lower than the
deprecate version, then the assertion won't be enabled.
The test verfies the fix by adding the older profile an asmjs folder.
Differential Revision: https://phabricator.services.mozilla.com/D24542
--HG--
extra : moz-landing-system : lando
CreateMutableFile() doesn't allow empty name, we should check it before
further processing to avoid assertion failure.
Differential Revision: https://phabricator.services.mozilla.com/D23999
--HG--
extra : moz-landing-system : lando
We avoid removing subsumed hints for out-of-flow and column-span frames
in RestyleManager::ProcessPostTraversal(). We should do something
similar here.
Differential Revision: https://phabricator.services.mozilla.com/D24578
--HG--
extra : moz-landing-system : lando
This login should not show up in tests that don't expect it once we allow non-matching formSubmitURLs.
Differential Revision: https://phabricator.services.mozilla.com/D23443
--HG--
extra : moz-landing-system : lando
Added files to UNIFIED_SOURCES and removed conflicts. Files that required flags still remain in SOURCES. SOURCES use "StrictOrderingOnAppendListWithFlagsFactory" base class and UNIFIED_SOURCES use "StrictOrderingOnAppendList" base class. As of now I do not think there is an option to add flags for the later. So the files requiring flags are kept in SOURCES.
Differential Revision: https://phabricator.services.mozilla.com/D23795
--HG--
extra : moz-landing-system : lando
With the current code we'll eventually detect the cycle, but will take much
more, creating many shadow trees unnecessarily. Take for example the following:
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="133" height="232774">
<style>
symbol { display: block }
</style>
<symbol id="svg-sprite" viewBox="0 0 133 230866">
<title>svg-sprite</title>
<symbol id="svg-sprite" viewBox="0 0 133 230866">
<title>svg-sprite</title>
<use xlink:href="#svg-sprite" width="500" height="500" />
</symbol>
<use xlink:href="#svg-sprite" y="1601" width="133" height="228958" />
</symbol>
<use xlink:href="#svg-sprite" y="1601" width="133" height="230866" />
</svg>
Before this patch, we'd create an svg use element subtree for #svg-sprite. That
subtree will contain two other <use> elements, one under the <symbol>, one not
under it.
Both point to #svg-sprite, but we fail to detect we're an ancestor since the
element #svg-sprite we're looking at is the clone of the #svg-sprite element.
Thus we need to take a look at mOriginal instead (which is the <use> element
under #svg-sprite) rather than at the clone.
Yeah, I had to draw the trees, it's messy :)
Blink and WebKit do something slightly different (they check the element id
directly[1]). That's not 100% correct, since you can have multiple elements with
the same ID.
[1]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/svg/svg_use_element.cc?l=560&rcl=861855dcb8c39ba8d42497247d433277858df79b
Differential Revision: https://phabricator.services.mozilla.com/D24565
--HG--
extra : moz-landing-system : lando
The shield historgram was reporting once per content blocking event, now it reports per page load.
Differential Revision: https://phabricator.services.mozilla.com/D24017
--HG--
extra : moz-landing-system : lando
