1801693 - Persist search term RTL orientation doesn't match the websearch RTL orientation

Status: NEW

(Firefox :: Address Bar, defect, P3)

Description

[Cristian Baica [:cbaica], Release Desktop QA]

Attachment: google rtl bug

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.

Comment 1

[James Teow [:jteow]]

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.

Comment 2

[James Teow [:jteow]]

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.

Comment 3

[Cristian Baica [:cbaica], Release Desktop QA]

Attachment: google screenshot

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.

Comment 4

[James Teow [:jteow]]

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

Comment 5

[Chris Bellini (:cbellini)]

Is this no longer reproducible?

Comment 6

[Cristian Baica [:cbaica], Release Desktop QA]

Hey Chris,
Yes, this is still reproducible, with the same steps mentioned in comment 0.