Summary of major changes:
* Bookmarks, history, and tabs restriction chars now enter search mode. I added
a method to UrlbarProviderHeuristicFallback to return a result with a keyword
when one of these is used.
* This fixes other bugs like recognizing aliases that are entered at the
beginning of non-empty search strings, and not quasi-re-entering search mode
when search mode is already entered and you type another alias.
* The heuristic now determines whether we enter search mode, similar to how it
also determines whether we autofill. When the heuristic has a keyword but no
keyword offer, and the keyword is one of the recognized search mode keywords,
then we enter search mode, cancel the current query, and start a new query
with the remainder of the search string after the keyword.
* I slightly changed how we detect an alias, but only when update2 is
enabled. Now, an alias must be followed by a space; otherwise, the alias is
not recognized and instead just remains part of the seach string. Because if
we don't do that, then you end up in a strange situation after typing an alias
but before pressing space: The heuristic says "Search with <engine with the
alias>", but we haven't entered search mode yet because you haven't typed a
space yet. This is true for both @aliaes and non-@aliases.
* A consequence of the previous point is that we can still autofill @aliases
with a trailing space, which IMO is important. Then, once the user types any
char (space or not), we immediately enter search mode with the query being
whatever char they typed. This is less important after bug 1658605 landed, but
it's still good to have.
* Previously, `UrlbarView.onQueryResults` called UrlbarInput in order to
autofill after the first result is received. This is circuitous becaue the
input already has an `onFirstResult` method, which I now use to enter search
mode when appropriate. So I moved the autofill call from UrlbarView to
`UrlbarInput.onFirstResult`.
* As I mentioned, I improved some test framework and simplified some related
product (non-test) code. For example:
* I removed `UrlbarUtils.KEYWORD_OFFER.NONE` in favor of just leaving
`keywordOffer` as `undefined`.
* `tailOffsetIndex` can now be `undefined` if it's not relevant.
* I removed empty-string `icon` properties from payloads in favor of
`undefined`.
* In tests, I ignore `undefined` but present properties in payloads so they
don't count when comparing payloads with `deepEqual`.
* We weren't previously comparing `result.source` and `result.type` in
xpcshell tests, and that's important IMO, so I added checks for those and
updated tests.
* `isSearchHistory` is redundant, so I removed it. For form history, we
should be checking `result.source == HISTORY` and `result.type == SEARCH`.
* A bunch of tests needed to be updated for this new behavior.
Differential Revision: https://phabricator.services.mozilla.com/D87944
Also fix WindowGlobalParent.drawSnapshot() to render the currently visible
viewport when called with a null rect, and clarify the webidl comment.
Differential Revision: https://phabricator.services.mozilla.com/D87971
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
We want this to be turned on for nightly users by default. The page range is still a WIP,
so we should hide that section for now.
This also adds the pref to the "Nightly Experiment" panel, turned on by default.
Differential Revision: https://phabricator.services.mozilla.com/D85907
This attribute can be used to force non-tab extension browsers to be loaded in
the correct BrowsingContextGroup, and also subsumes the existing
sameProcessAsFrameLoader uses in extension code.
Differential Revision: https://phabricator.services.mozilla.com/D85652
A late getEventTimings RDP request is being cancelled while we are exiting the test case and we have already closed the devtools toolbox.
The related network request is very likely unrelated to the scenario being tested (I suspect it may be an HTTP request triggered by some
privileged code and being automatically added to the webconsole panel, it is not unlikely that we are not explicitly checking if the http
requests logged in the webconsole are actually related to the extension that the devtools toolbox is targeting).
In the meantime, the attached patch is adding to the PromiseTestUtils's "global allow list" the rejections for any late RDP request
that may still be pending while the test is exiting.
Differential Revision: https://phabricator.services.mozilla.com/D86000
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
The problem has 2 folds.
The first one is that the shutdown function on DevToolsExtensionPageContextParent
wasn't called, which means the target was never destroyed. This is fixed by
overriding unload in DevToolsExtensionPageContextParent instead of shutdown, so
the function gets called and the target destroyed.
The second issue was that a single webextension could create 2 targets, and since
we only keep track of a single target, we would miss one. This is fixed by putting
the call to watchTargets in getCurrentDevTools in a promise, so subsequent calls
that might occur before the resulting promise isn't resolved don't end up calling
watchTargets a second time.
Differential Revision: https://phabricator.services.mozilla.com/D83935
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
This causes the browser to steal focus from any element that was focused prior
to the completion of the remoteness flip. This is particularly a problem for
fission because every cross-origin navigation requires a process switch.
This code is still necessary for "normal" session restores (see bug 1410591),
but focus is handled elsewhere for remote navigations.
Differential Revision: https://phabricator.services.mozilla.com/D82783
The previous code, emitting the event from Toolbox.onTargetAvailable,
wasn't waiting for the call to TargetList.startListening which is done
from TargetList.onTargetAvailable.
Differential Revision: https://phabricator.services.mozilla.com/D82664
