Browser-laptop: URL on the URL bar cannot be changed once it is autocompleted

[luixxiul]

Describe the issue you encountered: URL on the URL bar cannot be changed once it is autocompleted

1 Open https://www.chromium.org/
2 Open https://www.chromium.org/Home
3 Open https://download-chromium.appspot.com/
4 Input chro
5 Push the down key three times
6 Push the right key

-> Autocompleted URL = chromium.org/Home

Expected behavior: The autocompleted URL should be changed to https://download-chromium.appspot.com/

• Platform (Win7, 8, 10? macOS? Linux distro?): Windows 10

• Brave Version: 0.12.10 RC1

• Any related issues:

[shriram]

A related issue.

The most common thing I want to do is go to code.pyret.org/editor .

I go to the URL bar and type "co". It auto-completes to

code.pyret.org/editor#share=0Bxr4FfLa3goOeU1aMFdPSD [fake URL]

which is a URL that I once pasted in or visited (can't even remember, it was a one-time thing).

Okay, Brave has auto-completed overly specifically. Fine. I put my cursor at the # and hit C-k to kill the rest of the line.

What does it do? It kills the rest of the line, and a moment later, puts it _back in place_. So if by accident I've hit C-k Enter, well, I'm visiting the wrong URL.

I hit C-k again. It looks stable. I hit Enter.

It takes me to

https://code.pyret.org/editor#share=0Bxr4FfLa3goOeU1aMFdPSD

And maybe because I'm visiting this URL (inadvertently) so many times, it keeps coming back up as the URL I surely want.

It's hard to describe how hard it is to _not_ visit that URL and to go to code.pyret.org/editor instead.

[bradleyrichter]

I confirmed this bug today. Must be fixed.

cc @bbondy

[diracdeltas]

@shriram i've hit that same bug a lot of times, and agree it needs to be fixed. in the meantime, if you hit delete/backspace before hitting enter, it should delete the autocompleted part and go to the URL you typed.

i think autocomplete should always prioritize the shortest completion entry for a given prefix match, not necessarily the most-visited one.

[bsclifton]

+1 on what @diracdeltas said :smile:

It would be great to do both: prioritize shortest and then (for ones of equal length) sort by most visited

[bbondy]

i think autocomplete should always prioritize the shortest completion entry for a given prefix match, not necessarily the most-visited one.

@aekeus thoughts?

[bradleyrichter]

@diracdeltas Great find...this alone may solve most of the problem

chrome does:

brave does:

[bsclifton]

@diracdeltas here is a similar issue:
https://github.com/brave/browser-laptop/issues/5878

Deleting doesn't cause it, but trying to select using keyboard sure does. My issue sounds like a dupe of this one, but I do have some good STR

[diracdeltas]

@bradleyrichter i talked with @bbondy about that UI (right-arrow to enter the autocomplete entry) on slack a while ago. it would be a large change but probably worth it in the long run.

AFAICT google does this by stacking two transparent input elements on top of each other

[luixxiul]

the milestone was reset to 0.13.3

[hugobuddel]

The behavior seems to have changed a bit since the original report, but is still there in 0.19.95 (on Linux at least).

After following the three urls in the original report, these are the results when typing 'chro':

Two down presses (correct behaviour):

Three down presses (incorrect behaviour):

Pressing the right key in the correct case will show the entire URL in an editable form. Pressing the right key in the bad case will only show 'chro' for editing. Going back up and down is possible.

The problem seems to be with where the part of the url is matched. E.g.

• Searching for 'www': incorrect behavior
• Searching for first part after 'www', in this case 'chro' for www.chromium.org: correct
• Searching for first part of domain other than 'www', in this case 'downl': correct
• Searching for second part of domain, in this case 'appsp': incorrect
• Searching for part of the path, in this case 'Home': incorrect
• Searching for TLD, in this case 'org': incorrect
• Searching for 'abou' for 'about:blank': correct
• Searching for 'blan' for 'about:blank': incorrect
• Searching for any two terms (even twice the same like 'chro'): incorrect
• Searching for a term in the title (not url): incorrect

It seems to me that in all the above cases it should be possible to edit the URL. As in, I cannot fathom any situation in which it is desirable to not being able to edit the URL, nor any scenario in which it is prohibitively hard to implement an editable URL. I can't even imagine what would have caused these two cases to be treated differently. There must be different code paths somewhere, but why?

Searching for two terms seems to behave differently anyway, for example 'top sites' and 'brave pages' are always missing even though they would match.

Also, while writing this issue I noticed this: you cannot click on the auto complete items if you switched focus to another window.

The entire behavior of the auto complete is weird to me. E.g. typing 'issue' (singular) will show https://github.com/brave/browser-laptop/issues in the history, but 'issues' (plural) will not. 'issues' will show individual issues like https://github.com/brave/browser-laptop/issues/5767. What I try to do in such cases is: 'right arrow' to select url, 'ctrl-backspace' to delete issue number, 'enter' to go to the base url. But that is impossible due to this bug. So I have to do 'enter' to go to url, wait for it to load, 'ctrl-l', 'right arrow', 'ctrl-backspace' (or whatever edits desired), 'enter'.

Being able to edit the URL in auto complete is so ingrained in my muscle memory that it is really hard to unlearn, and there seems no reason why Brave does not support this properly.

[rebron]

Closing this bug as wontfix and tracking/opening in brave-core.