A test case is added to make sure this is fixed.
We also add the ability to not run a given test case in the color test.
Differential Revision: https://phabricator.services.mozilla.com/D35493
--HG--
extra : moz-landing-system : lando
The problem is that on switching back to the first tab (see the bug), userTypedValue is non-null when URLBarSetURI is called. Therefore the proxy state can't be valid. Something about bug 1529931 caused userTypedValue to go from null to non-null in this case. Details below, but the summary is that we shouldn't be calling UrlbarInput.setValueFromResult when opening the history popup, because setValueFromResult sets userTypedValue.
Before bug 1529931, result.autofill would always be undefined for the first result in the history popup, because we didn't allow UnifiedComplete to return an autofill result for the search triggered by the history popup. After that bug, UnifiedComplete could return an autofill result in that case -- and it likely would since the first result in the history popup has a very high frecency, which also makes it eligible for autofill.
The problem with having an autofill result in the history popup is that it triggers the input.setValueFromResult() call in UrlbarController.receiveResults [1], and setValueFromResult sets userTypedValue. So when the user opens the history popup, userTypedValue gets set to a non-null value (input._lastSearchString).
The fix is to not allow autofill for the history popup. After making that fix on revision https://hg.mozilla.org/mozilla-central/rev/5e2a3b886e64, the bug went away.
However, after I made that fix on a fresh tree, the bug still happened. It turns out that input.setValueFromResult still ends up getting called, by UrlbarView._selectItem [2], which is called when results are received [3]. The fix for this afaict is just to pass `updateInput: false` to _selectItem.
The autofill-related fix doesn't seem to be necessary at all anymore (likely due to the substantial changes to autofill since that bug landed), but I left it in anyway since it seems right to not allow autofill results for the history popup.
One other useful bit of info is that userTypedValue is set to null by tabbrowser on page load [4], so that's how userTypedValue has a null value when the bug manifests and it goes from null to non-null.
[1] https://hg.mozilla.org/mozilla-central/file/5e2a3b886e647af1968b9e52a6672bdeee2a0d6f/browser/components/urlbar/UrlbarController.jsm#l150
[2] https://searchfox.org/mozilla-central/rev/da14c413ef663eb1ba246799e94a240f81c42488/browser/components/urlbar/UrlbarView.jsm#685
[3] https://searchfox.org/mozilla-central/rev/da14c413ef663eb1ba246799e94a240f81c42488/browser/components/urlbar/UrlbarView.jsm#220
[4] https://searchfox.org/mozilla-central/rev/da14c413ef663eb1ba246799e94a240f81c42488/browser/base/content/tabbrowser.js#5118
Differential Revision: https://phabricator.services.mozilla.com/D35505
--HG--
extra : moz-landing-system : lando
No one includes `license.hunspell`, so we don't need our custimze block (`#include "config.h"`)
Also, some files isn't updated to 1.6.1, so we should update it.
Depends on D35516
Differential Revision: https://phabricator.services.mozilla.com/D35517
--HG--
extra : moz-landing-system : lando
This change comes in two parts. First, the code in WindowGlobalChild was changed
to detect the in-process case, and instruct the nsFrameLoader to become a
non-remote nsFrameLoader, and second the logic in WindowGlobalParent was updated
to ensure that the OwnerProcessID is updated after the change.
Differential Revision: https://phabricator.services.mozilla.com/D35060
--HG--
extra : moz-landing-system : lando
Because the return address cannot be used to uniquely identify script/pc, this
is unfortunately quite different from what we do for Baseline/Ion code.
The strategy is as follows:
* When the profiler is enabled, ensure each JitScript has a pointer to the
profile string (released when the script is finalized).
* The BaselineInterpreter code is registered with the JitcodeMap.
* The profiler code treats interpreter frames like C++ Interpreter frames,
instead of doing the return address based mapping.
Differential Revision: https://phabricator.services.mozilla.com/D31052
--HG--
extra : moz-landing-system : lando
This makes running without mach more consistent. e.g. running
`make -C $objdir/toolkit/library/rust target` makes the cargo log
verbose, and adding `-s` makes it less verbose.
Differential Revision: https://phabricator.services.mozilla.com/D35521
--HG--
extra : moz-landing-system : lando
When the `MOZ_RUST_TIER` environment variable is set, we enable a separate
tier that builds rust code only. This is useful to measure build times for
rust code separately from other compilations.
Differential Revision: https://phabricator.services.mozilla.com/D35501
--HG--
extra : moz-landing-system : lando
Fixed an issue where we were trying to set some attributes on a null object due to the fact that
the view had not finished rendering.
Differential Revision: https://phabricator.services.mozilla.com/D35515
--HG--
extra : moz-landing-system : lando
This adds an API for fetching security info per frame, no matter if we have
a certificate error or a valid certificate.
I tried to make this work in a Fission-compatible way, let me know if this
is the right approach.
Differential Revision: https://phabricator.services.mozilla.com/D34354
--HG--
extra : moz-landing-system : lando
Adds GeckoChildProcessHost::GetAll() and use it in ChromeUtils::GetProcInfo()
Differential Revision: https://phabricator.services.mozilla.com/D33920
--HG--
extra : moz-landing-system : lando
This changes CreateClippedDrawTarget so that instead of taking
a max size and a transform it just takes a user space rect of
the desired bounds.
This change allows the caller to not worry about the computing
a max size based on the current clip. Instead this responsibility
is lowered into the specific backends.
The main motivation for this work is to allow blob recoordination
to create recordings that don't depend on the current clip.
Some additional benefits are that the API is easier to use and
as can be seen simplifies the SVG masking code because it doesn't
need to track surface offsets manually.
It's also an important step towards removing all the uses of
gfxContext::GetClipExtents which will let us get rid of the separate
clipping stack in gfxContext and help us move off of gfxContext
completely.
Most backend implementations of CreateClippedDrawTarget are relatively
simple. DrawTargetCapture is modified to track the current clip rect
so that it can create a new DrawTargetCapture of the appropriate size
without needing to worry about lazy resolution.
Differential Revision: https://phabricator.services.mozilla.com/D33363
--HG--
extra : moz-landing-system : lando
