Right now the Quick Actions provider is active when not in a search mode or when in the Actions search mode. This works like other providers that have a corresponding search mode.

But typing its restrict token > followed by a valid search string doesn't work. Normally, when you type a restrict token like * or %, followed by a search string, the provider in question will return results equivalent to what it would find in its search mode. You can also type the restrict token and hit Spacebar to enter the Quick Actions search mode, and that works as expected. But for Quick Actions, if you type the restrict token and then immediately type the search string (like >view source), you won't get any quick action results.

That's because it isn't added to the context as a source here, and it's also further complicated because the provider itself only returns results for strings that 1) contain the full keyword, or 2) are fully contained in a keyword. So, once it's added as a source, the search string >view source actually does return a quick action result, but the search string >view sou does not, because it doesn't contain a full keyword, and none of the keywords contain the restrict token >.

So, if the restrict token matches, we should compare the looped prefixes to the input minus the restrict token. Then we will get the same results (from this provider) that we would get if we didn't type the token, or if we were in the Quick Actions search mode.

We should also be able to disable suggest.quickactions and still be able to get quick action results by entering the Quick Actions search mode or using the > token. The reason we're not able to do that is just because of the isActive check — we can just replace searchMode.source with restrictSource to take advantage of the fact that we added Quick Actions in updateSourcesIfEmpty.

This allows the Quick Actions urlbar provider to show results when the
user has entered a search string like >view so. The user can already
get these results by entering a string like > view so, since the space
after the token will make us enter the Quick Actions search mode. But
normally you can also filter relevant results without the space, e.g.
*bookmark name. This patch also fix a problem where the Quick Actions
search mode is always available, even if it's incapable of producing
results. You can test that by disabling browser.urlbar.suggest.quickactions
and browser.urlbar.shortcuts.quickactions and then typing > into
the urlbar. The Awesome Bar won't suggest any quick action results, and
it won't show a one-off button for the search engine, but you can still
enter the empty search mode. Other providers with local search modes
(bookmarks, history, open tabs) don't have this issue. You can still get
results by entering % for example. Disabling browser.urlbar.suggest.openpage
will just prevent the Awesome Bar from suggesting open pages when you
haven't entered the Tabs search mode or entered the % token. So this
patch brings the Quick Actions behavior in line with other similar
providers'. If Quick Actions suggestions are disabled, they will only
show up if you go looking for them by using the > token or entering
the Quick Actions search mode.

The severity field is not set for this bug.
:adw, could you have a look please?

For more information, please visit auto_nag documentation.

Dale, is this on your radar?

Hey thanks for the ping, I had taken a look over the patch but was unsure about the expected behaviour of the other search restriction modes when dealing without spaces. I agree that it would be nice for the different search modes to behave in the same way. Cheers

(Closing this since the search mode issue is fixed in bug 1789644, and the restriction mode issue won't matter as restriction modes are expected to be removed in bug 1545336)