User Agent: Mozilla/5.0 (Windows NT 10.0; rv:66.0) Gecko/20100101 Firefox/66.0

Steps to reproduce:

In the firefox address bar i wrote $1, by doing the same in chrome it converts it in local currency based on your IP

Actual results:

But after pressing enter button, in the search results you will get the result of 1 instead of $1. (I use google only)

Expected results:

It should convert that amount in local currency.

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0

Hi,

I have tested your issue on latest FF release (66.0.3) and if I wrote $1 in address bar the result is like in the photo that you attached here (left side of photo), but if I wrote 1$ the result is like in the photo, right side, meaning the expected result.
Are you using the latest version of FF, 66.0.3? If no, can you please update it and retest this using latest FF release and test the both situations that I have mentioned upper, with 1$ and $1 and report back the results?

Thank you for your report.

I think this is because $ is a restriction character in the address bar intended to make address bar results to look at just web addresses.

It works fine in the search bar, but not in the address bar. It is a little strange, as although it is restricting results, it still says n - Search with <engine>. Maybe it should be made so that if the search option is chosen, the restriction character is still part of the search?

(In reply to Alin Ilea from comment #1)

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0

Hi,

I have tested your issue on latest FF release (66.0.3) and if I wrote $1 in address bar the result is like in the photo that you attached here (left side of photo), but if I wrote 1$ the result is like in the photo, right side, meaning the expected result.
Are you using the latest version of FF, 66.0.3? If no, can you please update it and retest this using latest FF release and test the both situations that I have mentioned upper, with 1$ and $1 and report back the results?

Thank you for your report.

Hi,
I have just checked my FF is latest v66.0.3 32bit
In the right side chrome browser is running with a search query of $1 and it works fine but why not FF?
I have tried both queries on FF and 1$ gives the expected result.
I wish to draw your attention for a new query, just type %241 in address bar of FF and you'll see the google homepage in FF while for the same query you'll get another result in chrome.

Why this difference, this is very inconvenient for explorers who wish to explore more and more and because of this misbehave by browsers, It is problematic
Thanks

(In reply to Mark Banner (:standard8) from comment #2)

with <engine>`. Maybe it should be made so that if the search option is
chosen, the restriction character is still part of the search?

That seems right to me.

We could require to type a space after the restriction token, apart from ?, because historically the docshell always forced a search for ?something.
That would make these 2 code paths similarly just checking for the search restriction
https://searchfox.org/mozilla-central/rev/8d290159a6f80f5e33e2bd35c0e4b2df283a18c5/browser/components/urlbar/UrlbarTokenizer.jsm#305,313

All special characters should require a space, except for the "?" to be used to searched based on these categories:
https://searchfox.org/mozilla-central/rev/28ed523a3ed5dbf5f6b008cf1e28a9e8a8597b5e/browser/components/urlbar/UrlbarTokenizer.jsm#72-80

This may need input from UX, because we might break muscle memory for technical users that are not use to adding a space after the special character.

As far as I can tell now this is working as expected with a space being required after the restriction token, searches for "^1" or "$1" go straight to google

So after discussion with Dao

As initially reported this bug has been resolved, searching for "$1" searches google for "$1" without removing the restriction token. However when the user types "%1" then we will only search for tabs without showing that we are in tab search mode which is something we may want to fix