1602812 - Accel+L sometimes fails to select the address bar value

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect, P1)

Description

[Hal Wine [:hwine] use NI!]

STR:

1. start nightly with new profile
2. navigate to any page, e.g. https://mozilla.org
3. use ctrl-L to select awesome bar contents
4. note that entire URL is selected (this is old behavior)
5. edit the url in any manner, e.g. append '#'
6. click in page to defocus awesome bar
7. use ctrl-L to select awesome bar again

What happens:

• cursor is placed at end of URL, no active selection

What is expected:

• entire URL is selected, as before

Notes:

• I see this with the megabar set either way, but it "feels" like it started with the introduction of the megabar mode.
• this was on Win10, but I'm assuming it's generic
• muscle memory has "switch to tab; ctrl-L; ctrl-C; switch to document; paste link". Now, sometimes, a ctrl-A has to be added, but not always.

Comment 1

[Hal Wine [:hwine] use NI!]

I received one report in IRC that this was not reproducible on linux, so changing platform.

Just in case it matters:

• I'm on a MS Surface Pro, which can operate in "tablet" mode.
• I'm also on the Microsoft Insider fast ring, so have a newer OS version than retail

Comment 2

[Hal Wine [:hwine] use NI!]

also reported as non-reproducible on win7 in irc #nightly

Comment 3

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

This is probably part of the Retained results changes from bug 1593964, though I cannot reproduce it.
I'm on this page, I CTRL + L, RIGHT, add "#", click content, CTRL +L and the text is fully selected.

What am I missing?

Comment 4

[B.J. Herbison]

I'm seeing this on Linux, but not every time. I tried the steps to reproduce and didn't reproduce.

Immediately after I tried I tried the STR I wan across the problem in my normal activities. I copied part of the URL in tab 1 to the URL in tab 2, and later returned to tab 1 and pressed control-L and the URL wasn't selected. But the actual process involved more steps and I haven't figured out a consistent STR.

Comment 5

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

I can reproduce this consistently by adding a letter and then deleting it:

Ctrl+L, RIGHT (arrow), a, backspace, click content, Ctrl+L

At the final Ctrl+L the whole address is selected briefly, but then the cursor moves to the end. It gets stuck doing this on each Ctrl+L until I type something new into the bar.

I'm on Windows 10, Nightly 20191210095443. This machine does have a touch screen but I'm not using it during the test, and it isn't currently in tablet mode.

Comment 6

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

mozregression led me to this range but that's just when the update1 megabar prefs got turned on.

I ran again with --pref "browser.urlbar.update1:true" "browser.urlbar.update1.expandTextOnFocus:true" "browser.urlbar.update1.view.stripHttps:true" and got this range, which seems to confirm this was caused by bug 1593964.

(Also, F6 (switch between chrome and content) works just as well as "click content" for exercising this.)

Comment 7

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Some of these may actually be expected, we must check after we fix bug 1601450, then things should be clearer.

Comment 8

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

(In reply to Adam Gashlin (he/him) [:agashlin] from comment #5)

I can reproduce this consistently by adding a letter and then deleting it:

This is pretty much bug 1601450, for which I have a patch in review.
But this bug was reported WITHOUT the backspace step. If the matter is just returning to the initial url, this would just be a dupe of bug 1601450.

We need steps to reproduce that won't edit the text to return to the initial value, like comment 0. Or maybe the initial steps were not precise enough.

Comment 9

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

Oops, sorry, putting the regressionwindow-wanted keyword back up.

Comment 10

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Now that bug 1601450 landed, please update to the latest Nightly and try to reproduce the problem, having specific steps helps us.

Comment 11

[Hal Wine [:hwine] use NI!]

:mak - I still have the problem in buildid 20191211214629 using the STR from comment 0

per hg.m.o the bug 1601450 fix is included in that build. :/

Comment 12

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Could you please attach a log from about:support?

(In reply to Hal Wine [:hwine] (use NI, please) from comment #0)

2. navigate to any page, e.g. https://mozilla.org

Please be more specific about exactly what you do. Do you type or paste? which string exactly? Do you confirm with Enter?

5. edit the url in any manner, e.g. append '#'

Also here, if you could be more specific, it may help, which actions do you take to edit?

• I see this with the megabar set either way, but it "feels" like it started with the introduction of the megabar mode.

do you mean that if you set browser.urlbar.update1 to false and restart Firefox (so you see the old results panel taking whole window width, instead of the panel as large as the input field), you can still reproduce?

Comment 13

[Hal Wine [:hwine] use NI!]

(In reply to Marco Bonardo [:mak] from comment #12)

Could you please attach a log from about:support?

Problem no longer present in build 20191212095326, to which Fx updated when I launched again.

In case someone wants to repro on the old build, I answered the questions below.

(In reply to Hal Wine [:hwine] (use NI, please) from comment #0)

2. navigate to any page, e.g. https://mozilla.org

Please be more specific about exactly what you do. Do you type or paste? which string exactly? Do you confirm with Enter?

I type: "<C-l>www.mozilla.org<enter>"

5. edit the url in any manner, e.g. append '#'

Also here, if you could be more specific, it may help, which actions do you take to edit?

Multiple ways show the problem, but for sure typing this does: "<C-l><right>#<enter>"

• I see this with the megabar set either way, but it "feels" like it started with the introduction of the megabar mode.

do you mean that if you set browser.urlbar.update1 to false and restart Firefox (so you see the old results panel taking whole window width, instead of the panel as large as the input field), you can still reproduce?

That was referring to how I experience it in my working profile. In the new profile used for this report, browser.urlbar.update1 has the value true.

Comment 14

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

(In reply to Hal Wine [:hwine] (use NI, please) from comment #13)

(In reply to Marco Bonardo [:mak] from comment #12)

Could you please attach a log from about:support?

Problem no longer present in build 20191212095326, to which Fx updated when I launched again.

could you please check with mozregression which changeset fixed it?

Comment 15

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

WFM until we know what fixed it.

Comment 16

[Hal Wine [:hwine] use NI!]

mozregression output:

2019-12-13T11:33:03: INFO : Narrowed inbound regression window from [bd7b2d89, 0a45507a] (3 builds) to [c1274fa6, 0a45507a] (2 builds) (~1 steps left)
2019-12-13T11:33:03: DEBUG : Starting merge handling...
2019-12-13T11:33:03: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=0a45507aa14adf61f7453fb4445126389893fef0&full=1
2019-12-13T11:33:03: DEBUG : Found commit message:
Bug 1601450 - Further restrict the retained results behavior. r=dao

If the user types a full url, confirms it, and then focuses the urlbar, we should
not

When focusing the address bar after typing and confirming a page, we end up reopening
the view because the search string is the same. This causes unexpected noise and
selection problems (the url is not selected anymore).
This patch changes the behavior so we don't reopen on valid pageproxystate, that
seems to make sense considering the feature scope of restoring an abandoned search.

Additionally, make the keyboard shortcut not trying to reopen the view if it's
already open, to avoid messing up with the selection.

Finally, restore the appropriate allowAutofill status from the last context.
This may still cause us to not autofill something that was previously autofilled,
if 2 tabs contain the same exact search, but that's an edge case, so acceptable.

Differential Revision: https://phabricator.services.mozilla.com/D56635

Comment 17

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Why did you reopen the bug, can you reproduce it again?

Comment 18

[Hal Wine [:hwine] use NI!]

I read your close note as "closing WFM until mozregression supplied", so I reopened when I added that info.

Comment 19

[Alexandru Trif, Desktop QA [:atrif]]

Reproduced with Firefox 73.0a1 (20191210212905) on Windows 10x64 and STR from comment 5.
The issue is verified fixed with Firefox 73.0b5 (20200115020958) on Windows 10x64, macOS 10.15 and Ubuntu 18.04.