Some tests made some assumptions about the number of returned entries
by performance.getEntries, and these assumptions are not valid
anymore once we added new entries.
Depends on D66463
Differential Revision: https://phabricator.services.mozilla.com/D68645
* Add a check for `queryContext.searchMode` in
`UrlbarProviderHeuristicFallback._matchUnknownUrl`. We should not match a URL
when search mode is active, in addition to the existing check for a
restricting source.
* Move the aforementioned checks to the top of the method so that we avoid when
possible the more expensive string escaping and parsing currently at the top
of that method.
* Add a test task.
* Beef up the existing test tasks.
Differential Revision: https://phabricator.services.mozilla.com/D87189
We need to exit search mode when a page loads in the current tab. We may need to
exit search mode for page loads in other tabs too: If you're in search mode,
click a slow link, switch tabs, and the page loads in the meantime, then search
mode should be not be entered when you switch back. I don't think we handle that
case correctly right now, and this patch doesn't address that at all. That's
worth doing in another bug because I think the fix will be different.
At first I added an `onLocationChange` method to UrlbarInput that was called by
`XULBrowserWindow.onLocationChange` in browser.js [1], just like we have an
`onLocationChange` in UrlbarProviderSearchTips called by
`XULBrowserWindow.onLocationChange`. But we need to potentially exit search mode
any time `input.setURI` is called. `setURI` happens to be called by
`XULBrowserWindow.onLocationChange`, one of the several places that calls it
[2].
`setURI` is also called when switching tabs. Bug 1647899 already took care of
handling search mode for tab switches, but it would be nice to handle all this
in one place. `setURI` is also how `userTypedValue` is restored in the input,
and of course `userTypedValue` is something we need to restore when switching
tabs, just like search mode. For these reasons I moved per-tab search mode
restoration to `setURI` as part of this.
I'm also changing the name of the second parameter in `setURI`. I wasn't sure
whether it's true iff we're switching tabs, so I tracked down why that param was
added. It was added in bug 1478348, and comment 21 confirms it was added to tell
`setURI` and `XULBrowserWindow.onLocationChange` when they're being called due
to a tab switch. To make this clearer, I renamed the param and added some
javadoc for `XULBrowserWindow.onLocationChange`.
[1] https://searchfox.org/mozilla-central/rev/50cb0892948fb4291b9a6b1b30122100ec7d4ef2/browser/base/content/browser.js#5205
[2] https://searchfox.org/mozilla-central/search?q=symbol:%23setURI&redirect=false
Differential Revision: https://phabricator.services.mozilla.com/D87172
It has some properties which make it footgunny, especially in the face of
Fission. Callers should use WindowGlobalChild.innerWindowId instead.
Differential Revision: https://phabricator.services.mozilla.com/D82801
When a modal dialog is cancelled, the inertness for other elements
is reverted. However, in order to have the new state (non-inert)
effective, Firefox needs to do a frame flush. This flush is taken
place when it's really needed.
In browser_pioneer_us.js, we have some usage of some buttons when
the flush hasn't taken place yet, so the test fails because the
buttons are not clickable. To fix the test, we add a
getBoundingClientRect() call to force frame flushes to the
corresponding buttons.
Differential Revision: https://phabricator.services.mozilla.com/D86877
* Removing front end for the checkbox that allows users disable accessibility services
* Removing already expired telemtry probe for preferences.prevent_accessibility_services
Differential Revision: https://phabricator.services.mozilla.com/D86994
* Check both the useSystemViewer flag and the preferredAction for that mime-type when deciding to not open PDFs into pdf.js
* Don't set alwaysAskBeforeHandling to true when toggling off the "Always open in system viewer" context menu item.
Differential Revision: https://phabricator.services.mozilla.com/D86992
CLOSED TREE
Backed out changeset 17df14f0b129 (bug 1200896)
Backed out changeset 5d9e9bd12cd2 (bug 1200896)
Backed out changeset 7f016de8d52f (bug 1200896)
I can reproduce this reliably after refreshing my tree and applying the patch to
bug 1657918. It seems to be permanent in fact. The problem is that a previous
test (or the test itself, since this is a failure in verify mode) leaves the
mouse over the heuristic result, which causes it to be highlighted and show its
action text ("Search with Google"). The test is checking that the action text is
hidden.
We just need to synthesize a mousemove away from the view as the test starts. We
do something similar in a few tests already, although sometimes we use
`EventUtils.synthesizeNativeMouseMove` instead of what I use here. I tried that
function first but it didn't work here, so I went with the other one we use,
`EventUtils.synthesizeMouse` with `mousemove`.
Differential Revision: https://phabricator.services.mozilla.com/D87015
