Found in

• Fx 108.0b4

Affected versions

• Fx 108.0b4
• Fx 109.0a1

Affected platforms

• Windows 10
• Ubuntu 22.04
• macOS

Preconditions

• browser.urlbar.showSearchTerms.featureGate set to true.

Steps to reproduce

1. Launch Firefox.
2. In the address bar input: 11 22 33 and press enter.

Expected result

• Orientation of the search in the address bar matches the orientation displayed in the websearch.

Actual result

• Search term orientation doesn't match.

Regression range

• Not a regression.

Additional notes

• The issue occurs for Google and Bing. For both those engines, the websearch box has an RTL orientation.
• The DDG websearch has 'normal orientation, so the search terms orientation currently match.

Here's how I tested on a Mac:

1. Download a Hebrew version of Nightly
2. Enable showSearchTerms.featureGate
3. Switch my keyboard to Hebrew
4. Type either a set of non-numeric Hebrew characters or Hebrew characters with a number
5. Do a search

While using a mixture of text and numbers, I found the search term matches the ordering of characters in a search results page.

When the search consists entirely of numbers, the term in the urlbar won't match.

After some digging, it's because in SearchEngine, we call Services.textToSubURI.ConvertAndEscape(this.queryCharset, data). It does a conversion of the characters into a UTF-8 string. The difference is we encode a pure number string in the same order as they are input since there's nothing to suggest otherwise, whereas the the search engines encode the numbers in reverse.

Actually, I'm wrong that it only happens if it's just numbers. If we have a mixture of RTL and LTR characters, we'll see this same issue.

I think I understand the search partners reasoning for differences. Their search input box is RTL, so when you type a string "123 456", it'll appear in the input box as "456 123". Making a search will encode the search term as "123+456".

In contrast, the urlbar input won't apply any re-ordering until the user types an RTL character.

I am not sure if this got fixed for google or it still displays the text in the wrong order, but comparing to the initial screenshot, it looks better.
I am leaving the bug open as the issue still occurs for bing.

Hmm, I didn't do anything to address this bug, possibly a by-product of some modification to the Urlbar w.r.t. RTL?