Make sure we continue to leave JS un-minified for Nightly builds and add a missing FENNEC_NIGHTLY to AppConstants.jsm which got missed in bug 1547710.
Differential Revision: https://phabricator.services.mozilla.com/D29724
--HG--
extra : moz-landing-system : lando
This was erroneously removed in bug 1546597.
Also restores the original order of writing to the update.status file in relation to reloading the update manager.
Differential Revision: https://phabricator.services.mozilla.com/D29795
--HG--
extra : moz-landing-system : lando
We could do some work to make sure that we don't unnecessarily
PushLayer, but that's better left for the future.
Differential Revision: https://phabricator.services.mozilla.com/D29744
--HG--
extra : moz-landing-system : lando
1. In bug 1545278, Ted is making our story about guarding on object pointer identity more robust. Since I am adding a new guardSpecificObject call in the ConstStringSplit patch, it seemed reasonable to add guardSpecificFunction now instead of later.
2. It's not directly relevant in the current patch, but in a previous version of the StringSplit patch (before I realized we could delete the whole thing) it turned out that calling isSelfHostedFunctionWithName on an arbitrary function can trigger assertions, because GetSelfHostedFunctionName assumes isExtended, but isSelfHostedBuiltin does not necessarily imply isExtended (in the case of nested anonymous functions).
3. Fixing the format string in a JitSpew message I added in a previous stack.
Depends on D29535
Differential Revision: https://phabricator.services.mozilla.com/D29536
--HG--
extra : moz-landing-system : lando
I started changing StringSplit to attach outside of self-hosted code, to match ConstStringSplit. Upon closer examination, the StringSplit IC doesn't actually add any value, and we're better off deleting it. The generated code calls StringSplitHelper, which ends up doing almost exactly the same thing as the call to intrinsic_StringSplitString it replaces. When we first wrote the patch (bug 1366377), the advantage was that we got to skip a lookup to determine the group of the resulting object. However, a subsequent patch created a single group for every StringSplitString result, which is basically free to look up.
I couldn't write a microbenchmark where the StringSplit IC made any difference, so let's just delete it and simplify our codebase.
Depends on D29534
Differential Revision: https://phabricator.services.mozilla.com/D29535
--HG--
extra : moz-landing-system : lando
Some native functions (for example, the Array constructor) have constructor-like behaviour even when called in a non-constructing context. We still want to create template objects for these cases. This fixes a noticeable regression in Speedometer (particularly in EmberJS-debug).
Depends on D29533
Differential Revision: https://phabricator.services.mozilla.com/D29534
--HG--
extra : moz-landing-system : lando
While trying to pin down a performance regression, I realized that both the new and the old implementations of ConstStringSplit are broken. Three years ago, as part of some ES6 work, we changed String.prototype.split to call a self-hosted String_split function instead of native str_split. In turn, String_split calls intrinsic_StringSplitString in the case we care about. However, because the call to intrinsic_StringSplitString is in self-hosted code, we would only get value out of this stub if there was only one caller of String_split in the entire program.
This patch changes ConstStringSplit to look for the self-hosted String_Split function, which means we can attach a stub to the user script instead of self-hosted code. It also adds support in BaselineInspector for extracting metadata about the string split from the stub, which enables the Ion version of this optimization.
Depends on D29532
Differential Revision: https://phabricator.services.mozilla.com/D29533
--HG--
extra : moz-landing-system : lando
When pushing arguments for a JIT call, we push the callee value onto the stack, and then immediately pop it off. This is a remnant of the old implementation.
This patch removes that wart, with a small detour to rewrite/recomment alignJitStackBasedOnNArgs for clarity.
Differential Revision: https://phabricator.services.mozilla.com/D29532
--HG--
extra : moz-landing-system : lando
Like Part 2, I choose mCachedPrefISize because grid and flex container
are using it.
Differential Revision: https://phabricator.services.mozilla.com/D29748
--HG--
extra : moz-landing-system : lando
Instead of renaming it to mMinISize, I choose mCachedMinISize because
both grid and flex container frames use mCachedMinISize for similar
purpose.
Differential Revision: https://phabricator.services.mozilla.com/D29747
--HG--
extra : moz-landing-system : lando
This patch is generated by running the following script under layout/,
and then manually delete the FIXME comment in LayoutConstants.h
#!/bin/bash
function rename() {
find .\
-type f\
! -path "./obj*"\
! -path "./.git"\
! -path "./.hg"\
\( -name "*.cpp" -or\
-name "*.h" \)\
-exec sed -i -e "s/$1/$2/g" "{}" \;
}
rename NS_INTRINSIC_WIDTH_UNKNOWN NS_INTRINSIC_ISIZE_UNKNOWN
Differential Revision: https://phabricator.services.mozilla.com/D29746
--HG--
extra : moz-landing-system : lando
This sometimes introduces an environment change ping when it shouldn't, and
hides that install_addon doesn't actually trigger an environment change.
Depends on D29388
Differential Revision: https://phabricator.services.mozilla.com/D29389
--HG--
extra : moz-landing-system : lando
This allows improving all tests exceptions without requiring
any specific to be done in each tests.
I'm also moving a few imports to head.js to share the most into head.js.
Differential Revision: https://phabricator.services.mozilla.com/D29414
--HG--
extra : moz-landing-system : lando
Start the `TabObserver` from `RemoteAgent.listen` in order to prevent
having the tests to manually start it.
Start it from `listen` instead of `init` as we do stop the `TabObserver` from
`stop` and `stop` is the reverse of `listen`, not the reverse of `init`.
Differential Revision: https://phabricator.services.mozilla.com/D29412
--HG--
extra : moz-landing-system : lando
These tests need to be disabled to get a green run on the Android x86_64
test platform. The failures in toolkit/components/extensions are
concerning and definitely require follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D29843
--HG--
extra : moz-landing-system : lando
* Create new network.trr.resolvers pref which is a JSON array of objects with a name and url representing each resolver
* Add menulist to represent the resolver choices, and a "custom" option to use the network.trr.custom_uri as the trr.uri value
Differential Revision: https://phabricator.services.mozilla.com/D29393
--HG--
extra : moz-landing-system : lando
When UrlbarInput.uninit is called after customize mode ends, uninit calls this.inputField.controllers.removeControllerAt(0), which is supposed to remove the input's CopyCutController inserted in the constructor. But the controller at index 0 at that point is not the CopyCutController. Instead it's some built-in controller that supports these commands (at least these): cmd_charPrevious, cmd_charPrevious, cmd_beginLine, cmd_endLine. (Verified by adding logging to nsXULControllers::GetControllerForCommand.) That's why arrow left/right and home/end don't work after ending customize mode.
The problem is that this.inputField.controllers in the constructor and this.inputField.controllers in uninit (when customize mode ends) are not the same. I wasn't able to track down why, but I'm guessing that the textbox or something in its state is being reset or cloned when customized mode ends or maybe right after it starts. The CopyCutController isn't in the controllers array at all on uninit. (Verified by adding support for cmd_adw and iterating through the controllers array, looking for a controller supporting cmd_adw.)
Note that urlbarBindings.xml has a try-catch around removeController(), I'm guessing for what turns out to be this reason: https://searchfox.org/mozilla-central/rev/7944190ad1668a94223b950a19f1fffe8662d6b8/browser/base/content/urlbarBindings.xml#190
However, CopyCutController *is* in the controllers array when customize mode starts. So I added a new gURLBarHandler.customizeStart method that calls a new UrlbarInput.removeCopyCutController method.
Other things I tried or thought of doing:
Call gURLBarHandler._reset on customize start instead of end. Problem with that is that the UrlbarInput ends up getting immediately recreated because some other parts of the browser access gURLBar at that time. (Of course I replaced the `gURLBar = this.urlbar` assignment in _reset with another lazy getter definition.)
Just don't worry about removing CopyCutController at all. That seems bad because then we'd leak it, unless the controller is removed or the controllers array is emptied at some point by XUL, and I'm not at all certain about that. (Although I guess this is effectively what awesomebar does, given the link above!)
Differential Revision: https://phabricator.services.mozilla.com/D29613
--HG--
extra : moz-landing-system : lando
This can fix the 1 color difference intermittent failure problem, it's small enough to be ignored.
Differential Revision: https://phabricator.services.mozilla.com/D29773
--HG--
extra : moz-landing-system : lando
