1601450 - Select location bar plus type while in about:config no longer deletes location bar contents

Status: RESOLVED FIXED

(Firefox :: Address Bar, defect, P1)

Description

[Tracy Walker [:tracy]]

This is a regression in Firefox Nightly in recent builds as early as 4:46 PST 20191204. Iris Nighty build validation revealed this first in https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&tier=1%2C2%2C3&revision=13fb375eaf14bd9fae5c607aa60015d2b3bd0f2d&searchStr=iris%2Cnightly-linux64-shippable%2Fopt&selectedJob=279610716 Subsequent test runs have failed.

Steps to reproduce:

1. Open about:config
2. Select the location bar with keyboard shortcut (cmd or ctrl + l)
3. type a few letters

Tested results:
about:config is left in the location bar with whatever you typed following it

Expected results:
typing should have overwritten the about:config text

Try the same in location bar with a url present and you get correct results. I expect the location bar shouldn't act any differently if we're in aboutconfig.

Comment 1

[Marco Bonardo [:mak]]

almost surely bug 1593964

Comment 2

[Tracy Walker [:tracy]]

This occurs in any about: page that keeps about:<page> in the location bar; ie about:about, about:crashes, about:library etc.

Comment 3

[Tracy Walker [:tracy]]

I've found this is reproducible outside of about:config with specific steps to reproduce as follows.

1. Put an "m" into your clipboard
2. Open a new tab (the location bar should be selected)
3. Paste the "m"
4. use keyboard shortcut to select the location bar
   -- notice an item from suggestions list is auto-completed in the location bar with the auto-completed part selected but not the initial "m"
5. Paste the "m" again.

Tested results:
"mm" in the location bar.

Expected results:
Just one "m" in the location bar.

If you replace the initial paste of an "m" into the location bar with typing an "m", the rest of the test steps produce expected behavior.

Comment 4

[Marco Bonardo [:mak]]

yeah, we are activating retained results when the shortcut is used, because the string is the same as the last search.
It's interesting that pasting an "m" brings up different results than typing an "m", likely it's due to allowAutofill being false on paste.

Comment 6

[Marco Bonardo [:mak]]

Attachment: 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.

Comment 7

[Natalia Csoregi [:nataliaCs]]

Landed: https://hg.mozilla.org/integration/autoland/rev/0a45507aa14adf61f7453fb4445126389893fef0

Comment 8

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/0a45507aa14a