I have https://bugzilla.mozilla.org/show_bug.cgi?id=1635234 in my history which has the title "FOG's C++ API Design". I open a new tab, type "C++" and the only result in the suggestions is to search google for it (I have search suggestions turned off, but I don't think that should matter for a query against the places db).

I'd expect bug 1635234 to show up. If I type "API Design" it's in the list.

:mhoye notes that titles with "+=" are also a little strange suggesting that maybe it's a urlsafe string encoding thing?

To test this out, try the following method

1. Open a tab and tell it to go to data:text/html,<title>This is a title with C!! C@@ C## C$$ C%% C^^ C&& C** C(( C))</title>
2. Open another tab and try to type things into it that'll let you switch to the first open tab

Things that don't work: C##, C$$, C^^, C** (in addition to the C++ that doesn't find bug 1635234)

Also of interest is that the tooltip when I hover on the first tab truncates at the first # in the title. Neat.

it happens because + is the restriction token for tags, so c++ says "search for c++ in tagged bookmarks" that restricts the search to bookmarks.
Another common string that may be broken atm, is searching for a percentage, like "51%". The cases you pointed out are also valid, though those are less likely to be typed or have less severe restrictions.

We do this so that you can restrict a search typing a restriction token just after your search string without having to add an artificial space, but it's of course breaking use cases.
Probably for any restriction token that is not "?" we should require a space. The "?" case is special because it may be common to type a question and expect a search, and it's natural to write a question with the "?" attached to the last word.

I must also note that even searching for "++i" may not work, for a similar reason, we allow to type a restriction token immediately followed by a search string. I think the breakage is less sever in that case, just because it's less likely users start a search with a special char.

This may be a dupe because it's known from some time, I didn't search for similar bugs yet.

https://hg.mozilla.org/mozilla-central/rev/a2941bad7532

The patch landed in nightly and beta is affected.
:harry, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Comment on attachment 9153494 [details]
Bug 1636961 - Require a space in front of trailing non-search restriction tokens. r?adw

Beta/Release Uplift Approval Request

• User impact if declined: Without this patch, users don't receive history results or search suggestions for queries like c++ or A+. This is part of the work done on address bar papercuts, much of which is landing in 78. It would be nice to get this into 78 to accompany the other changes, particularly with 78 being ESR.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: 1. On a fresh profile, open a new tab, enter data:text/html,<title>This is a title with C!! C@@ C## C$$ C%% C^^ C&& C** C++ C(( C))</title> into the address bar, and hit enter.

2. In a new tab, search for each of C##, C$$, C^^, C**, C++ in the address bar. All of those queries should show the switch-to-tab result for the page in the other tab.

• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Small front-end patch with a test that's baked on Nightly for 5 days. Affects which address bar results are presented, but does not affect the underlying data. Backout would be easy in case of regressions.
• String changes made/needed:

Comment on attachment 9153494 [details]
Bug 1636961 - Require a space in front of trailing non-search restriction tokens. r?adw

approved for 78.0b5

https://hg.mozilla.org/releases/mozilla-beta/rev/1e63ef497880

Reproduced the initial issue with an old Nightly build 78.0a1 (build id: 20200511094328) using Windows 10.
Verified - Fixed in latest Nightly build 79.0a1 (build id: 20200608213811) and Beta 78.0b5 (build id: 20200608141819) using Windows 10 and Ubuntu 18.04.