2059897 - Selection is not highlighted correctly in Address Bar

Status: ASSIGNED

(Firefox :: Address Bar, defect)

Description

[Rong Bao [:csmantle]]

Attachment: Screen recording demonstrating this bug

When selecting text in the Address Bar in Fx 154.0b5, the selection isn't highlighted as usual. However, the functions of the selection, such as replacing, copying, and dragging, work normally. See also the attached screen recording.

Running Mozregression on mozilla-beta from 2026/07/26 to 2026/08/01 showed the revision https://phabricator.services.mozilla.com/D314889 (https://phabricator.services.mozilla.com/D314607, Bug 2058134) as the result, thus filling the regressor field accordingly.

UA

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

Comment 1

[Rong Bao [:csmantle]]

Attachment: mozregression screenshot

Comment 2

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 2058134

:emilio, since you are the author of the regressor, bug 2058134, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 4

[Alice0775 White]

I can reproduce the issue on Windows11 and Ubuntu24.04

Comment 7

[Emilio Cobos Álvarez [:emilio]]

[Tracking Requested - why for this release]: Let's not ship this regression :)

Comment 8

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 2059897 - Remove urlbar selection border radius from beta. r=#theme

This is removed on nightly already and it causes Gecko to not draw the
native selection now, see the regressing bug.

Comment 11

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined/Reason for urgency: Severe urlbar regression
• Code covered by automated testing?: yes
• Fix verified in Nightly?: no
• Needs manual QE testing?: yes
• Steps to reproduce for manual QE testing: comment 0
• Risk associated with taking this patch: low
• Explanation of risk level: Removes a rule that we want to get rid of anyway for 155.
• String changes made/needed?: none
• Is Android affected?: no

Comment 12

[Emilio Cobos Álvarez [:emilio]]

Alternative to this would be to back out the regressor and live with that bug for one more release.

Comment 24

[Jilvin Jacob [:jilvin]]

This appears to have had a significant negative impact on the user experience.

See Reddit Discussion (https://www.reddit.com/r/firefox/s/uXYNGoWBPV)

Comment 25

[Jilvin Jacob [:jilvin]]

Could we also add a regression test to ensure this issue is caught if it regresses in the future?

Comment 26

[Jilvin Jacob [:jilvin]]

I have a question about the ESR uplift process.

From the bug history, it appears this patch was uplifted to Beta and then approved for ESR about 8.5 hours later. I was wondering whether that amount of Beta exposure is generally considered sufficient before an ESR uplift.

Since ESR is intended to be the most conservative and stable release channel, I was curious how this decision was evaluated, especially given that this change later resulted in regressions (such as the URL bar text selection/highlighting behaviour).

I'd appreciate any insight into the reasoning behind the timing of the ESR approval. I'm asking because I'd like to better understand the release management process.

Comment 32

[Emilio Cobos Álvarez [:emilio]]

(In reply to Jilvin Jacob [:jilvin] from comment #25)

Could we also add a regression test to ensure this issue is caught if it regresses in the future?

Well, the change here is CSS only (there are tests for the ::selection behavior, introduced in the regressing bug)... I don't think we have reftests for the browser UI, or how meaningful would those be.

Comment 33

[Emilio Cobos Álvarez [:emilio]]

(In reply to Jilvin Jacob [:jilvin] from comment #26)

From the bug history, it appears this patch was uplifted to Beta and then approved for ESR about 8.5 hours later. I was wondering whether that amount of Beta exposure is generally considered sufficient before an ESR uplift.

Note that ESR uplift != ESR release. The regressing patch is in the ESR repo, but hasn't made into an ESR release yet, I don't think. (For that matter, requesting tracking so that we don't miss it).

Since ESR is intended to be the most conservative and stable release channel, I was curious how this decision was evaluated, especially given that this change later resulted in regressions (such as the URL bar text selection/highlighting behaviour).

I'd appreciate any insight into the reasoning behind the timing of the ESR approval. I'm asking because I'd like to better understand the release management process.

I requested the ESR uplift because it fixes a regression introduced in FF 153, with duplicates, and the fix was straight-forward.

The problem with this particular uplift was that, while I was aware of the dependency on the urlbar radius removal (bug 2056981, see the commit message on that patch) I didn't notice that the rules bug 2056981 removed weren't all gated with @media -moz-pref("browser.nova.enabled") {, so there was a hidden dependency on that bug.

Comment 34

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 2059897 - Remove urlbar selection border radius from esr153.

This is removed on nightly already and it causes Gecko to not draw the
native selection now, see the regressing bug.

Original Revision: https://phabricator.services.mozilla.com/D315778

Comment 35

[Phabricator Automation]

firefox-esr153 Uplift Approval Request

• User impact if declined/Reason for urgency: See above
• Code covered by automated testing?: yes
• Fix verified in Nightly?: no
• Needs manual QE testing?: yes
• Steps to reproduce for manual QE testing: comment 0
• Risk associated with taking this patch: low
• Explanation of risk level: Removes CSS rule that is ineffective with nova disabled and that is removed with the final nova design anyway.
• String changes made/needed?: none
• Is Android affected?: no