Search mode is effectively a replacement for/improvement on one-offs, token aliases, and custom aliases. Unfortunately, these all treat Places results differently and we've regressed Places results for custom aliases.

With update2 off, if you set an alias g for Google and type g coffee you'll get history/bookmarks results for any coffee-related Google pages you have in Places, plus Google suggestions for "coffee". With update2 on, when you type the space after g, you enter Google search mode. Search mode only shows suggestions, so you lose Places results for the query.

This is most annoying for OpenSearch engines that don't provide suggestions. For example, I have Bugzilla as an engine and have a bz alias for it. Part of my workflow is to search bz <bug name> to search through my Bugzilla history to find bugs. Now, when I type bz, I enter Bugzilla search mode. Since Bugzilla doesn't provide suggestions, I just get a search heuristic.

Part of the motivation around search mode was to get a cleaner search experience, so I understand not showing Places results for some engines. For example, we might not want to show Places results for the "general purpose" search engines we're defining in bug 1647889.

I asked UX about this, but this might require Product and UX meeting, which could take a while. I could see this being one of the main annoyances when update2 is preffed on in Nightly, so I'm setting this as a P1. Maybe we could land some kind of temporary fix ASAP.

I agree about needing product/UX input, but in case it's helpful, I can think of a few short term fixes in addition to yours about handling general purpose engines specially. Your idea might be better though.

• The search service knows which engines provide suggestions. We could not enter search mode for those engines; or at least not limit results to search results, but that would be a bit of a pain to implement probably.
• We could limit the number of search suggestion results and also fetch other types of results, similar to the second part of the previous point but for all engines.
• We can suggest that people use bookmark keywords instead of search engines where possible. In your Bugzilla example, you could add a bookmark for https://bugzilla.mozilla.org/buglist.cgi?quicksearch=%s with a keyword. But I think Dale is working on unifying bookmark keywords and search aliases? Presumably we'd enter search mode for bookmark keywords too at some point, so long term that's probably not even viable.

(In reply to Drew Willcoxon :adw from comment #1)

• The search service knows which engines provide suggestions. We could not enter search mode for those engines; or at least not limit results to search results, but that would be a bit of a pain to implement probably.

I think it would be confusing that some one-offs enter search mode and some do.

• We could limit the number of search suggestion results and also fetch other types of results, similar to the second part of the previous point but for all engines.

Sounds good. As a short term fix, I'm going to fetch both search and local results for search mode engines except for general-purpose engines. We might revise this behaviour when Product/UX get back to us on this.

This patch also restricts to only search results when Accel+K is used to access search mode.

ttps://treeherder.mozilla.org/#/jobs?repo=try&revision=c064886670769b8ea1a4a788fe1c04942452e805

Backed out for failures on browser_oneOffs_searchSuggestions.js

backout: https://hg.mozilla.org/integration/autoland/rev/5b4faf8f838301f19d6350f477dfd080ee6aeea8

push: https://treeherder.mozilla.org/#/jobs?repo=autoland&searchStr=windows%2C10%2Cx64%2Cwebrender%2Copt%2Cmochitests%2Ctest-windows10-64-qr%2Fopt-mochitest-browser-chrome-e10s%2Cbc5&revision=e5655c6b1c5ffdd51053ef37694cdd11718832cd&selectedTaskRun=SkweTIppQD626LhBxCeM4A.0

failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=312987195&repo=autoland&lineNumber=3949

[task 2020-08-14T03:00:07.594Z] 03:00:07 INFO - TEST-PASS | browser/components/urlbar/tests/browser/browser_oneOffs_searchSuggestions.js | Urlbar should never be in search mode without the corresponding attribute. - true == true -
[task 2020-08-14T03:00:07.594Z] 03:00:07 INFO - Buffered messages finished
[task 2020-08-14T03:00:07.594Z] 03:00:07 INFO - TEST-UNEXPECTED-FAIL | browser/components/urlbar/tests/browser/browser_oneOffs_searchSuggestions.js | Expected searchMode - {"engineName":"browser_searchSuggestionEngine searchSuggestionEngine.xml"} deepEqual {"source":3,"engineName":"browser_searchSuggestionEngine searchSuggestionEngine.xml"} - JS frame :: resource://testing-common/UrlbarTestUtils.jsm :: assertSearchMode :: line 409
[task 2020-08-14T03:00:07.594Z] 03:00:07 INFO - Stack trace:
[task 2020-08-14T03:00:07.594Z] 03:00:07 INFO - resource://testing-common/UrlbarTestUtils.jsm:assertSearchMode:409
[task 2020-08-14T03:00:07.595Z] 03:00:07 INFO - chrome://mochitests/content/browser/browser/components/urlbar/tests/browser/browser_oneOffs_searchSuggestions.js:test_returnAfterSuggestion/<:189
[task 2020-08-14T03:00:07.595Z] 03:00:07 INFO - TEST-PASS | browser/components/urlbar/tests/browser/browser_oneOffs_searchSuggestions.js | Expected textContent - "browser_searchSuggestionEngine searchSuggestionEngine.xml" == "browser_searchSuggestionEngine searchSuggestionEngine.xml" -

New build: https://treeherder.mozilla.org/#/jobs?repo=try&revision=2c43f3ce59aa18efe4b3e759b4f6daa9bfefb52b

https://hg.mozilla.org/mozilla-central/rev/9bfa6276ddc5

Bug 1659237 got me thinking about this more. I'm not sure this was the right fix. Form history and SERP restyling are related. Ideally we would have had form history all along, so when you type g coffee, your results would be filled with form history for all the coffee-related searches you've done over time. We haven't had form history all along, so the next best thing is to restyle SERPs so they appear as form history.

Re: typing bz without a query, that's bug 1657648 afaict, but that also depends on having form history and/or restyling SERPs.

Do you mean this isn't right in that we should be showing history for general-purpose engines, or that we shouldn't be showing history for any engine? If the latter, I disagree. Imo, searching for bz <bug name> is only really useful if I'm searching through history. I imagine this is the case with many specific-site search engines; your history is more likely to offer what you're looking for than site-wide search/suggestions.

The latter, but I see what you mean. I was thinking of the bz keyword having a SERP URL of https://bugzilla.mozilla.org/show_bug.cgi?id=%s, so when you type bz by itself, you get a list of bug numbers and aliases styled like form history, and you could type bz <partial bug number or alias> to narrow down the results. But you're talking about a way of searching for page titles restricted to Bugzilla, I think? I do wonder whether that's "proper" use of search engine keywords even if they've always worked like that... Maybe! At least the way I handle that scenario is to search for bugzilla foo without any keywords at all.

(In reply to Drew Willcoxon :adw from comment #13)

But you're talking about a way of searching for page titles restricted to Bugzilla, I think?

Yeah, although I could certainly use bugzilla foo like you suggest, or # bugzilla foo. I certainly don't want to block this bug based solely on my workflow. I can ask UX about this today.

UX would like us to add a pref for this behaviour so we can run user testing but generally they're happy with it. Also, there's a bug where sites not matching the search mode engine are leaking through. I'll file both bugs blocking this one.

Thanks, Harry.

I verified this issue using 82.0a1 (2020-09-14) on macOS 10.13 and Windows 10 x64.
Adrian could you help me with Ubuntu verification?

Verified as fixed using latest Nightly 83.0a1 2020-09-24 under Ubuntu 18.04 64-bit.