Skip to content
This repository has been archived by the owner on Dec 11, 2019. It is now read-only.

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

Closed
luixxiul opened this issue Nov 21, 2016 · 11 comments
Closed

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

luixxiul opened this issue Nov 21, 2016 · 11 comments

Comments

@luixxiul
Copy link
Contributor

luixxiul commented Nov 21, 2016

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:

@bbondy bbondy added this to the Backlog milestone Nov 22, 2016
@shriram
Copy link

shriram commented Nov 30, 2016

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
Copy link
Contributor

bradleyrichter commented Dec 1, 2016

I confirmed this bug today. Must be fixed.

cc @bbondy

@bradleyrichter bradleyrichter modified the milestones: 0.13.1, Backlog Dec 1, 2016
@luixxiul luixxiul added the bug label Dec 1, 2016
@diracdeltas
Copy link
Member

@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
Copy link
Member

+1 on what @diracdeltas said 😄

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

@bbondy
Copy link
Member

bbondy commented Dec 1, 2016

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

@aekeus thoughts?

@bradleyrichter
Copy link
Contributor

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

chrome does:
image

brave does:
image

@bsclifton
Copy link
Member

@diracdeltas here is a similar issue:
#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
Copy link
Member

@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 luixxiul modified the milestones: 0.13.3, 0.13.2 Feb 1, 2017
@luixxiul
Copy link
Contributor Author

luixxiul commented Feb 1, 2017

the milestone was reset to 0.13.3

@hugobuddel
Copy link
Contributor

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.

  • 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 rebron removed this from the Triage Backlog milestone Sep 9, 2018
@rebron
Copy link
Collaborator

rebron commented Sep 9, 2018

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

@rebron rebron closed this as completed Sep 9, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

8 participants