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

Status: RESOLVED WONTFIX

(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.

Comment 7

[Yazan Al Macki [:yazan]]

Attachment: Bug 1801693 - Make the URL bar's RTL rules match the rules of the active search engine. r?#urlbar-reviewers

Comment 8

[Drew Willcoxon :adw]

I'm going to take module owner's prerogative here and say that this is not a bug, or an enhancement, or something we should fix. There's discussion in the phabricator, but in summary, Firefox's UI should not be dictated by the UI of web pages it happens to load, and it certainly shouldn't change depending on the current tab.

If Product or UX wants to make this change, OK, we can discuss it further, but for now I'll close this.