1853044 - Sometimes editing a URL selected from address bar dropdown reverts to the previous one when pressing Enter

Status: RESOLVED FIXED

(Firefox :: Address Bar, defect, P2)

Description

[Adrian]

I very frequently start typing something in the address bar to edit it before navigating to it.
For example, I type my-admin because I know it'll autocomplete https://my-admin-portal.example.com/user/foo. I then edit the completed URL and replace foo with bar.
This is incredibly useful and I prefer this over creating bookmarks with search shortcuts - and it's more flexible because it works fine for pretty much everything I use regularly.

However, lately I noticed that occasionally (I was not able to figure out what exactly causes this to happens) as soon as I press Enter to navigate to the new URL, it reverts to the original URL and navigates to that one...

I think this started happening some weeks ago, so probably at some point during 118 or 117 (I'm on the beta channel).

Comment 1

[Marco Bonardo [:mak]]

There have been a few changes to heuristic results and autofill in 117 and 118, so I can see how this may be a regression from that work.

It would be nice to find more consistent steps to reproduce, can QA help us here?

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

This bug has been marked as a regression. Setting status flag for Nightly to affected.

Comment 3

[Cristian Baica [:cbaica], Release Desktop QA]

Hello Adrian,
Firstly we need to figure out if you have the adaptive history turned on. To check this pref, go to about:config and in the preference search bar, look for 'browser.urlbar.autoFill.adaptiveHistory.enabled'. Is that pref set to true?

Secondly, we have somehow managed to reproduce the issue(using adaptive history), but from what I could tell, that is somehow expected behavior. We tried accessing localhost page that was behind the localhost login page. So even if in the address bar, we input localhost.local/internet/page.html , we're taken to the localhost.local/login.html page. Could this also be the case for you?

Comment 4

[Adrian]

The pref is set to false.

And no, this is not related to websites redirecting. This is the browser changing the initial URL to something else.

BTW, I just read he description of adaptive history and it sounds like a cool feature. However, I think it should probably not be triggered at all if you select a URL from history but then edit it to something else before navigating to it!

Comment 5

[Dianna Smith [:diannaS]]

:cbaica by any chance is there any progress on finding a regression window?

Comment 6

[Cristian Baica [:cbaica], Release Desktop QA]

Unfortunately, we're unable to get a regression range, because we cannot reproduce the issue described in comment 0. If the issue still persists, maybe Adrian can provide some better steps in trying to reproduce this.

@Adrian is the issue still reproducible with the latest Fx 119 version that is currently on beta channel? If it is, did you find a reliable way in reproducing this?

Comment 7

[Adrian]

Attachment: ff-bug-demo.gif

Yes, I was just able to reproduce it right after upgrading to 119.0b4. I'm attaching a gif showing it.

Note that I have some custom userChrome css, hence the weird styling. But since this is just styling it should be completely unrelated. I also did not add any strange extensions that may interfere with the address bar.

Comment 8

[Donal Meehan [:dmeehan]]

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

There have been a few changes to heuristic results and autofill in 117 and 118, so I can see how this may be a regression from that work.

It would be nice to find more consistent steps to reproduce, can QA help us here?

:mak since QA can't reproduce this, is there anything else we can request from the reporter to try narrow this down?
For example, any logs that would be helpful?

Comment 9

[Marco Bonardo [:mak]]

Based on the gif, the selection should be cleared when the input string changes, and that doesn't happen.

I think I could reproduce the bug, by ensuring that condition happens.
Basically match some url, shift+left to select its end, type something else and press Enter BEFORE the results change.

I suspect this is a regression of Bug 1816572, because we probably clear the selection when new results arrive.
We should clear the view selection earlier if possible, or ignore the selection if it doesn't match the current search string.
I'ts also strange Enter is handled before the selection is cleared, as input happened so the urlbar event bufferer should await for results and delay the confirmation.
Needs some debug.

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 12

[Dianna Smith [:diannaS]]

:mak any update on this bug?

Comment 13

[Daisuke Akatsuka (:daisuke)]

I could reproduce this issue. I take a look at this bug.

Comment 14

[Marco Bonardo [:mak]]

Dale is also working on bug 1852442 that may also help here, that's why I was delaying a bit here.
Regardless,it would be better to fully understand if we're clearing the selection too late, while at the same time avoid flickering selection on the heuristic result (that may be a reason we don't clear selection early, needs debugging).

I think it's ok to work on this, just keep into account the patch/test may be bitrotted by bug 1852442.

Comment 15

[Marco Bonardo [:mak]]

indeed I cannot reproduce with the patch from bug 1852442 applied, that makes it a timing bug.

Comment 16

[Daisuke Akatsuka (:daisuke)]

Thanks, Marco.
Okay, I wait to fix bug 1852442, then check again.

Comment 17

[Daisuke Akatsuka (:daisuke)]

There was a case in the test case that I thought that it might be a bug.
https://searchfox.org/mozilla-central/rev/42acdc9cd5ae89222bdceeeaed7bacac755be48f/browser/components/urlbar/tests/browser/browser_autocomplete_enter_race.js#79-97
This is a test in which the user types ex and then types Enter right after it. This means, that only ex is shown on the urlbar at the time when the user types the Enter key. However, this test indicates that the progressing with the autofilled value (example.com) by ex is correct. But, at the time when the user typed Enter, as only ex is showing, we’d better search by ex without using autofilled value?
In a URL example, assuming example.com/test is on the urlbar, and assuming the value will be autofilled. Then, select the last word test as the same as the report, then type t and Enter immediately, we open example.com/test now. But we should open example.com/t instead since example.com/t is showing at the time when the user types Enter? What do you think?

Comment 18

[Marco Bonardo [:mak]]

(In reply to Daisuke Akatsuka (:daisuke) from comment #17)

This is a test in which the user types ex and then types Enter right after it. This means, that only ex is shown on the urlbar at the time when the user types the Enter key. However, this test indicates that the progressing with the autofilled value (example.com) by ex is correct. But, at the time when the user typed Enter, as only ex is showing, we’d better search by ex without using autofilled value?

We delay Enter (through the UrlbarEventBufferer) because users muscle memory tends to remember typing certain words will achieve a certain result.
For example, if I'm used to type "ex⏎" to go to example.com, it would be unfortunately if sometimes I end up on example.com, and sometimes on a search for "ex", and that would only depend on the speed at which providers return results.
That is mostly valid for the heuristic results.

The problem here was slightly different, as the user has typed a string that doesn't match what we end up visiting, for example we visit https://someurl/search when they selected "earch" and typed "ound", expecting a visit to https://someurl/sound.
Here there is also a non-heuristic result selected, that may be changing things.

I suspect bug 1852442 has wallpapered the problem, as now we update results every 16ms, so the likeliness for this to happen is very low.
But I also think the original problem, where the selection persists on input change, is still there... It requires debugging with modified code (like longer timers in UrlbarProvidersManager) to confirm.

Comment 19

[Daisuke Akatsuka (:daisuke)]

Attachment: Bug 1853044: Open page with edited value by user regardless of selected result

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/29784c387017
Open page with edited value by user regardless of selected result r=adw

Comment 21

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/29784c387017

Comment 22

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:daisuke, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox122 to wontfix.

For more information, please visit BugBot documentation.

Comment 23

[Donal Meehan [:dmeehan]]

Older issue, doesn't look like we would want to uplift at this point in the cycle.
This can ride the trains with Fx123.

Setting Fx122 to wontfix but please reach out if there is any concern.

Comment 24

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

I tried to reproduce this issue on Firefox 122.0 but I was unsuccessful.
Daisuke, given the fact that you were successful in reproducing, would you be so kind as to share the reproduction steps or any configuration needed in order to properly verify this issue? Thank you.

Comment 25

[Daisuke Akatsuka (:daisuke)]

Hello Ardelean!
Reproducible I said there was a different issue, I'm sorry.
At last, I also did not reproduce this issue unless changing the below variable which delay time for updating the urlbar result.
https://searchfox.org/mozilla-central/rev/c88ac92342d525fd69dbd4c29cd22984eaf9de78/browser/components/urlbar/UrlbarProvidersManager.sys.mjs#123
So, if we can make the updating slow manually somehow, we may be able to reproduce it, but I am not sure how to do it. Thus, I think it is very hard to reproduce.