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
Replace a couple of popup methods so that they call dirtyFrame(), so that reflows happen deterministically.
Differential Revision: https://phabricator.services.mozilla.com/D23734
--HG--
extra : moz-landing-system : lando
* In nsAutoCompleteController, the logic that determines whether the new search is a prefix of the old search is only done in HandleText, i.e., on input, not when the value is set programmatically.
* That logic is a lot more complex in nsAutoCompleteController.
* nsAutoCompleteController autofills in one case where quantumbar doesn't: when completing the "placeholder" string before starting a new search and waiting for the async results (thereby preventing flicker).
* Some nsAutoCompleteController state gets reset each time the awesomebar is focused (see calls to attachController() in the autocomplete binding, which sets the controller's input, which calls ResetInternalState()). That state is important in regard to autofill and the placeholder string. If it's not reset, then the autofill of one search will incorrectly affect the autofill of a later search.
Differential Revision: https://phabricator.services.mozilla.com/D22306
--HG--
rename : browser/components/urlbar/tests/browser/browser_UrlbarInput_autofill.js => browser/components/urlbar/tests/browser/browser_autoFill_caretNotAtEnd.js
extra : moz-landing-system : lando
I like the error message just as well without the class name. In fact, I think
the word "derived" is important to include here, so the message is even a
little better. The stack and line number make it super clear which constructor
we're talking about, so we're not really losing anything.
In Chrome, the error message is "ReferenceError: Must call super constructor in
derived class before accessing 'this' or returning from derived constructor".
Differential Revision: https://phabricator.services.mozilla.com/D23223
--HG--
extra : moz-landing-system : lando
This changes the order of some cleanup operations, harmlessly, to make
initialization and teardown more FIFO.
Differential Revision: https://phabricator.services.mozilla.com/D23222
--HG--
extra : moz-landing-system : lando
Otherwise you see font changes when hovering, which is not really desirable.
Differential Revision: https://phabricator.services.mozilla.com/D24116
--HG--
extra : moz-landing-system : lando
The graph contains some extra things like toolchains, fetches and packaging
tasks that people will almost never want to run on their own. This change gets
them out of the default fuzzy selection interface, and makes it so --full is
needed to schedule them.
Differential Revision: https://phabricator.services.mozilla.com/D24187
--HG--
extra : moz-landing-system : lando
Noticed by Ian Moody [:Kwan] while watching test output. (!)
The test was introduced in bug 515475, 10 years ago. However, the syntax used
in this patch seems to have been removed from SpiderMonkey around that time,
maybe even before the patch landed; that is, this is not among the syntax
removed in bug 517580. As far as I can tell, this test has never functioned
properly.
Differential Revision: https://phabricator.services.mozilla.com/D24236
--HG--
extra : moz-landing-system : lando
The current standard requires this function to have no own `name` property at
all; its `.name` would be inherited from `Function.prototype`. However, V8 and
JSC both already do what we do, so we're working to change the standard instead
of changing our behavior. See <https://github.com/tc39/ecma262/issues/1049>.
Differential Revision: https://phabricator.services.mozilla.com/D23263
--HG--
extra : moz-landing-system : lando
`resumeMedia` is used for resuming delayed autoplay, which have been replaced by notifying via the browsing context.
Differential Revision: https://phabricator.services.mozilla.com/D18139
--HG--
extra : moz-landing-system : lando
Replace the current way and use the new way in order to make this working well after enable Fission.
Differential Revision: https://phabricator.services.mozilla.com/D18137
--HG--
extra : moz-landing-system : lando
After enable Fission, we're not able to resume media in the different process, because the current way we use can only notify one process and would cause the media on other process can't be resumed.
Therefore, we should use the browsing context to notify the web content which might be on different processes.
Differential Revision: https://phabricator.services.mozilla.com/D18136
--HG--
extra : moz-landing-system : lando
`gecko_profiler_add_text_marker` was being passed a character pointer and a
length to construct a `nsDependentCString`. However, these values were coming
from a Rust `&str`, which is not null-terminated, causing an debug assertion to
be hit (and possible memory safety issues if mishandle the string). We now
construct an `nsDependentCSubstring` instead.
Differential Revision: https://phabricator.services.mozilla.com/D24032
--HG--
extra : moz-landing-system : lando
Disable the entire manifest file `toolkit/content/tests/browser/browser.ini` that deals with audio playback tests for windows10-aarch64.
Differential Revision: https://phabricator.services.mozilla.com/D24091
--HG--
extra : moz-landing-system : lando
Disable `browser_screenshots_cropping.js` due to constant failure of this test on windows10-aarch64.
Differential Revision: https://phabricator.services.mozilla.com/D24122
--HG--
extra : moz-landing-system : lando
Depends on D23872.
If you want to test the patch, I will post a try link afterwards to pull a valid queue
since my work depends on another bug that is almost ready to land but not yet landed.
Then you can open aboutdebugging-new by going to about:debugging-new
Differential Revision: https://phabricator.services.mozilla.com/D23874
--HG--
extra : moz-landing-system : lando
