search

brave / browser-laptop

[DEPRECATED] Please see https://github.com/brave/brave-browser for the current version of Brave
https://www.brave.com
Other
7.95k stars 975 forks source link

URL on the URL bar cannot be changed once it is autocompleted #5767

Closed luixxiul closed 6 years ago

luixxiul commented 7 years ago

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/

shriram commented 7 years ago

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 commented 7 years ago

I confirmed this bug today. Must be fixed.

cc @bbondy

diracdeltas commented 7 years ago

@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 commented 7 years ago

+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 commented 7 years ago

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

@aekeus thoughts?

bradleyrichter commented 7 years ago

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

chrome does: image

brave does: image

bsclifton commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

the milestone was reset to 0.13.3

hugobuddel commented 6 years ago

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): braveautook1e

Three down presses (incorrect behaviour): braveautobad1e

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.

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 commented 6 years ago

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