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
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
Bug 1284835 removed the hard-coded learn more link on cert and net error pages, which worked
for cert error pages because they explicitly set their own learn more links, but net error
pages were relying on the default href to be set. This wasn't revealed until bug 1530348
made about:neterror part of the new error pages.
The solution is simply to explicitly set the correct learn more link to net error pages.
Note that in the case of PR_END_OF_FILE errors, we were not previously showing a "learn more"
link. That was not intentional, as far as I can tell, but was caused by the bug fixed in bug 1477875.
Differential Revision: https://phabricator.services.mozilla.com/D35163
--HG--
extra : moz-landing-system : lando
With the removal of the old Chromium file_util code, we should no longer
be using temporary files with names starting with "org.chromium.", so the
crash reporter and main thread I/O test no longer need to recognize that
prefix.
Differential Revision: https://phabricator.services.mozilla.com/D34629
--HG--
extra : moz-landing-system : lando
The tests for unexpected main thread I/O had exemptions for the specific
paths that were being used for shared memory, which would cause it to
fail with the changes in this bug. This patch does two things:
1. On Linux, /dev/shm is always tmpfs (a memory filesystem), so it's not
going to cause disk I/O, and it's used by glibc to implement the POSIX
standard shm_open API. This allows all /dev/shm paths instead of
limiting it to a hard-coded prefix.
2. On MacOS, with the patches in this bug, we'll no longer use temporary
files for shared memory on current OS versions, but we still need them on
older versions to avoid an OS bug (https://crbug.com/project-zero/1671),
and they are backed by disk in this case, so we want to allow only the
IPC files. However, the path prefix has changed.
Differential Revision: https://phabricator.services.mozilla.com/D34628
--HG--
extra : moz-landing-system : lando
Bug 1545766 (D28442) tweaked PanelMultiView keyboard navigation to behave as expected for embedded browser elements.
This patch extends this to handle iframe elements such as used in the builtin Profiler panel.
In addition, it avoids setting tabindex="-1" on iframe and browser elements, since this breaks tabbing behavior in iframe elements (and possibly causes issues in browser elements as well).
iframe and browser elements are already focusable, so this isn't needed anyway.
Differential Revision: https://phabricator.services.mozilla.com/D34984
--HG--
extra : moz-landing-system : lando
With the removal of the old Chromium file_util code, we should no longer
be using temporary files with names starting with "org.chromium.", so the
crash reporter and main thread I/O test no longer need to recognize that
prefix.
Differential Revision: https://phabricator.services.mozilla.com/D34629
--HG--
extra : moz-landing-system : lando
The tests for unexpected main thread I/O had exemptions for the specific
paths that were being used for shared memory, which would cause it to
fail with the changes in this bug. This patch does two things:
1. On Linux, /dev/shm is always tmpfs (a memory filesystem), so it's not
going to cause disk I/O, and it's used by glibc to implement the POSIX
standard shm_open API. This allows all /dev/shm paths instead of
limiting it to a hard-coded prefix.
2. On MacOS, with the patches in this bug, we'll no longer use temporary
files for shared memory on current OS versions, but we still need them on
older versions to avoid an OS bug (https://crbug.com/project-zero/1671),
and they are backed by disk in this case, so we want to allow only the
IPC files. However, the path prefix has changed.
Differential Revision: https://phabricator.services.mozilla.com/D34628
--HG--
extra : moz-landing-system : lando
:root is potentially cheaper than #main-window, because IDs aren't actually guaranteed to be unique, so ID selectors are treated just like class selectors under the hood.
Changed #main-window to :root in browser/themes/shared/customizableui/panelUI.inc.css
Differential Revision: https://phabricator.services.mozilla.com/D35382
--HG--
extra : moz-landing-system : lando
Attributes that are related to Fluent-based strings intentionally weren't moved to element.dataset.
Differential Revision: https://phabricator.services.mozilla.com/D35113
--HG--
extra : moz-landing-system : lando
I named the INI file parameter "FallbackPage" so that people building these
configurations can quickly understand what this URL is for and don't have to
figure out what "manual download" means.
Differential Revision: https://phabricator.services.mozilla.com/D34359
--HG--
extra : moz-landing-system : lando
This workaround hands the top-level browser to nsContextMenu rather than the
mozbrowser in the RDM case. We need to do that since RDM does a lot of work
to make the inner mozbrowser _seem_ like the top-level browser, including
proxying messages from that top-most browser to the underlying mozbrowser.
This workaround makes us consistent with that model, and will have to do until
we can get bug 1559456 fixed.
Depends on D35077
Differential Revision: https://phabricator.services.mozilla.com/D35078
--HG--
extra : moz-landing-system : lando
In the content process case, preventing default stops the context menu event from being dispatched
within remote iframes, which is what causes bug 1558506.
In the parent process case, preventing default stops the nsXULPopupListener from opening the context
menu for us when we don't want ContextMenuParent to handle it, which we don't want to do.
Differential Revision: https://phabricator.services.mozilla.com/D35077
--HG--
extra : moz-landing-system : lando
