1912416 - Pressing Ctrl+Shift+Left Arrow while all texts are highlighted in address bar unselects them

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect, P3)

Description

[fornothingno.1]

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

Steps to reproduce:

Open new tab and type in address bar "test1 test2 test3" as an example.
Press Ctrl+A or select texts with mouse from left to right.
Press Ctrl+Shift+Left Arrow.

Actual results:

Only test1 test2 get selected for a split second then gets unselected.

Expected results:

test1 test2 gets selected leaving test3.

Comment 1

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:mak, could you have a look please?

For more information, please visit BugBot documentation.

Comment 2

[PeterJCLaw]

This reproduces for me in 129.0.2 (via snap) on Ubuntu 22.04.4 (with Xorg window manager).

Comment 4

[pokechu022]

Regressed in https://phabricator.services.mozilla.com/D212790 (which fixed 1896128). I have browser.urlbar.trimURLs disabled (and the trim HTTPS option doesn't seem to be present in stable releases, but if it was I'd turn it off too), though this behavior applies regardless of those settings

Comment 5

[pokechu022]

Looking at D212790, this seems to be something that's explicitly implemented: pressing control+left while all text is selected sets the cursor to position 0 and clears the selection. Behavior with left isn't mentioned in bug 1896128 at all though, and I don't think the current behavior makes sense.

If I enter the text "https://en.wikipedia.org/wiki/Main_Page" in a regular text field (e.g. this comment form) and then select "en.wikipedia.org/wiki/Main_Page", pressing left or control+left clears the selection and puts the cursor before "en". It doesn't act like pressing home at all.

With D212790 and URL trimming enabled, selecting "en.wikipedia.org/wiki/Main_Page" and then pressing left makes the "https://" visible but leaves the cursor before "en" (the same as a regular text field), while pressing control+left moves the cursor to before the "https". This is inconsistent behavior (though I guess it could be mildly useful to be able to choose between these in some cases, though I'm not sure how anyone would naturally discover it).

The big problem is that D212790 only checks for control+left without caring about if shift is held. This doesn't matter for home (shift+home and home when everything is selected should both clear the selection) but does matter for control+left (where shift does cause different behavior with a selection).

I wonder if Mak was thinking of FN+Left instead of Control+Left, which on some devices acts as home. The device I'm currently using doesn't behave that way, but I have another one that does; I'm not sure if that generates DOM_VK_HOME or something else.

Comment 6

[Marco Bonardo [:mak]]

We're differenciating the behavior between Home-like and Left-like shortcuts, though this case seems not handled properly.

(In reply to pokechu022 from comment #5)

With D212790 and URL trimming enabled, selecting "en.wikipedia.org/wiki/Main_Page" and then pressing left makes the "https://" visible but leaves the cursor before "en" (the same as a regular text field), while pressing control+left moves the cursor to before the "https". This is inconsistent behavior (though I guess it could be mildly useful to be able to choose between these in some cases, though I'm not sure how anyone would naturally discover it).

It's inconsistent, but we feel like it brings more value to the user, one case we're considering what is shown, while when we guess the user intent is more like Home we move back to position 0. It's also consistent with other browsers, so users expectations are not broken when moving across browsers.

The big problem is that D212790 only checks for control+left without caring about if shift is held. This doesn't matter for home (shift+home and home when everything is selected should both clear the selection) but does matter for control+left (where shift does cause different behavior with a selection).

True.

I wonder if Mak was thinking of FN+Left instead of Control+Left, which on some devices acts as home. The device I'm currently using doesn't behave that way, but I have another one that does; I'm not sure if that generates DOM_VK_HOME or something else.

No, I actually wanted to handle Ctrl+Left, and I missed the Shift case, my fault.
Though I'd also be curious to know which keycode Fn+Left generates on your keyboard.

Comment 7

[pokechu022]

Though I'd also be curious to know which keycode Fn+Left generates on your keyboard.

Looks like both Fn+left and Fn+F11 generate DOM_VK_HOME on the device in question (a Dell XPS laptop; I believe it would default to F11 being home and Fn+F11 being F11 but I swapped that in the BIOS). There is no dedicated Home key, and Fn+left being home isn't actually marked on the keyboard (though Fn+up and Fn+down are indicated as page up/page down). The current logic should work fine for this.

Comment 9

[Marco Bonardo [:mak]]

Attachment: Bug 1912416 - Ctrl+Shift+Left in the Address Bar should not unselect all. r=#urlbar-reviewers

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f44bddbea61a
Ctrl+Shift+Left in the Address Bar should not unselect all. r=urlbar-reviewers,daisuke

Comment 11

[BugBot [:suhaib / :marco]]

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

Comment 12

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/f44bddbea61a

Comment 13

[Mathew Hodson]

I think this is happening both when browser.urlbar.trimHttps is true and when it is false so this would affect Firefox 132.

Comment 14

[Marco Bonardo [:mak]]

This is about browser.urlbar.untrimOnUserInteraction.featureGate pref, not browser.urlbar.trimHttps.

#isHomeKeyUpEvent is only used here and maybeUntrimURL bails out

Comment 15

[Mathew Hodson]

My reading of the code is that it's this.selectionStart = this.selectionEnd = 0; that causes the text to be unselected. That's happening before and outside of #maybeUntrimUrl.

I'm able to reproduce the issue on WIndows 11 with Firefox 132 if I understand the steps in comment #0 correctly.

Comment 16

[Marco Bonardo [:mak]]

Oh, that's right, thank you for the pointer!
I should ask for uplift.

Comment 17

[Marco Bonardo [:mak]]

Attachment: Bug 1912416 - Ctrl+Shift+Left in the Address Bar should not unselect all. r=#urlbar-reviewers

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

Comment 18

[Phabricator Automation]

beta Uplift Approval Request

• User impact if declined: Ctrl+Shift+Left doesn't work as expected in the address bar
• Code covered by automated testing: yes
• Fix verified in Nightly: no
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: See comment 0
• Risk associated with taking this patch: low
• Explanation of risk level: trivial code change, limited impact
• String changes made/needed: none
• Is Android affected?: no

Comment 19

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/38472ab50355

Comment 20

[Ciprian Georgiu, Desktop QA]

I have reproduced this issue on Win 11 with an affected Nightly build (2024-08-09), using STR from comment 0.

The issue is verified as fixed on latest Nightly 134.0a1 and Beta 133.0b3 under macOS 13, Ubuntu 22.04 and Win 11.