Closed
Bug 659437
Opened 14 years ago
Closed 6 years ago
Tracking bug for URL autocomplete edge cases
Categories
(Firefox :: Address Bar, defect)
Firefox
Address Bar
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: limi, Unassigned)
References
(Blocks 2 open bugs)
Details
(Whiteboard: [Advo])
Bug 566489 landed, and I want a place where people can log their text editing edge cases (make sure you include platform!) and other issues encountered.
Currently reported:
* OmniBar add-on breaks the inline autocomplete
* Entering text causes a lot of flickering because the background color is changed on every keypress (comment was: "Please compare behavior with Chrome or Camino 2.1a1 (with the enabled "browser.urlbar.autofill" option).
* Ctrl-Backspace doesn't do what's expected (Windows)
* It broke keyword bookmarks. Now `ma<Enter>` tries to find a URL instead of expanding to my bookmark. (definitely an edge case, as keywords generally exist to be able to do things like "w cats" to search Wikipedia for "cats")
Please add other issues below, and we'll separate out bugs for the ones that are things we want to fix. There will be certain edge cases that may not be worth fixing, but I'd like to collect them here first.
Comment 1•14 years ago
|
||
As warned against in comment 13 of Bug 566489, I seem to get different behavior depending how quickly I hit Enter after typing.
With arewefastyet.com in my history, I sometimes get a google search for 'arewe' (if I hit enter quickly) and sometimes get arewefastyet.com (if I'm not fast yet).
Comment 2•14 years ago
|
||
(In reply to comment #1)
> As warned against in bug 566489 comment 13, I seem to get different
> behavior depending how quickly I hit Enter after typing.
>
> With arewefastyet.com in my history, I sometimes get a google search for
> 'arewe' (if I hit enter quickly) and sometimes get arewefastyet.com (if I'm
> not fast yet).
I strongly advocate for fixing this. It is ironic that a UX-efficiency win also costs the user in efficiency, because now the user has to wait for an async operation to get consistent results. We really should create a synchronous fast path for the inline autocompletion as described in bug 566489 comment 19.
Comment 3•14 years ago
|
||
(In reply to comment #0)
> * It broke keyword bookmarks. Now `ma<Enter>` tries to find a URL instead of
> expanding to my bookmark. (definitely an edge case, as keywords generally
> exist to be able to do things like "w cats" to search Wikipedia for "cats")
Just to confirm, this is referencing the fact that auto-complete ignores page/bookmark titles and only attempts to auto-complete URLs?
Reporter | ||
Comment 4•14 years ago
|
||
(In reply to comment #3)
> Just to confirm, this is referencing the fact that auto-complete ignores
> page/bookmark titles and only attempts to auto-complete URLs?
Yes, autocomplete should only complete URLs. If you want title completion, the awesomebar results will give you those. Two different ways of navigating the web.
Reporter | ||
Updated•14 years ago
|
Assignee: nobody → limi
Comment 5•14 years ago
|
||
(In reply to comment #0)
> * It broke keyword bookmarks. Now `ma<Enter>` tries to find a URL instead of
> expanding to my bookmark. (definitely an edge case, as keywords generally
> exist to be able to do things like "w cats" to search Wikipedia for "cats")
related to that; it's no longer possible to run js-bookmarklets via the location-bar.
Comment 6•14 years ago
|
||
(In reply to comment #5)
> related to that; it's no longer possible to run js-bookmarklets via the
> location-bar.
That's intentional; bug 656433.
Hi. I'm not sure, if the following behavior is a bug or not:
STR:
1.) visit "http://www.apple.com/de/"
2.) focus the location bar and type "apple"
-> Actual: "apple.com" is autofilled in the location bar
-> Expected: "apple.com/de/" should be autofilled in the location bar
Every other browser (Safari, Chrome and Camino) works like the expected behavior.
Comment 8•14 years ago
|
||
(In reply to comment #7)
> Hi. I'm not sure, if the following behavior is a bug or not:
The behavior you described is not what we intended to implement. See bug 566489 comment 0.
Comment 9•14 years ago
|
||
Shouldn't switch to tab be prioritised over an auto-completion of the same url? i.e. if I start typing planet as in planet.mozilla.org), and I have a tab by that url already open, I should be taken to the tab as per the legacy behaviour rather than having the url opened in a new tab.
Updated•13 years ago
|
Comment 11•13 years ago
|
||
(In reply to Paul [sabret00the] from comment #9)
> Shouldn't switch to tab be prioritised over an auto-completion of the same
> url? i.e. if I start typing planet as in planet.mozilla.org), and I have a
> tab by that url already open, I should be taken to the tab as per the legacy
> behaviour rather than having the url opened in a new tab.
+1
Comment 12•13 years ago
|
||
Shouldn't this block bug 746572 ?
Comment 13•13 years ago
|
||
(In reply to alex_mayorga from comment #12)
> Shouldn't this block bug 746572 ?
not at all.
Comment 14•12 years ago
|
||
In Firefox 14 beta, a weird behavior has appeared. "autoFill" feature adds "www." prefix to URL in location bar though neither browser's history nor bookmarks do contain corresponding URL with "www." prefix.
If I start to type, for example, "stack", then "stackoverflow.com" is automatically placed into location bar. It's correct.
But then, if I just press "enter" key, "www.stackoverflow.com" (with "www." prefix) is for some reason starting loading instead of "stackoverflow.com" that has been shown in location bar when I've started typing and pressed "Enter" key.
But if I start to type "stack", and then press "down-arrow" key once (thus choosing [from the URL list suggested by Firefox] _same_ URL as has been suggested by autoFill autocomplete) and _then_ press "Enter" key, "stackoverflow.com" (without "www." prefix) is opened as expected ("www." prefix is not prepended to the URL).
Neither my history nor bookmarks do contain the URL with "www." prefix. The "www." prefix is apparently added wrongly by autocomplete mechanism of Firefox when using autoFill feature (that's probably what's called inline autocomplete). Tested multiple times (with different URLs affected by the bug) in Library window opened via "Ctrl+Shift+H" keyboard shortcut.
The only workaround I've found is to "forget the site" with corresponding context menu-item of one of search/filter results in Library window. But that's undesirable and annoying since cookies are deleted too, and I'm forced to relogin to all sites that have been worked-around this way.
This bug is reproduced in both latest Firefox 14 beta (20120612164001) and Nightly (20120614075912).
Should I file a new bug for this?
Thanks.
Comment 15•12 years ago
|
||
Yep, please do.
Comment 16•12 years ago
|
||
Filed bug 765337 related to wrong www-prefix adding as described in comment 14.
Comment 17•12 years ago
|
||
another edge-case:
i opened a ftp-url twice, now every time autocomplete tries to open the ftp-url instead of the http-url, which i open at least once a week. maybe only http-urls should be autocompleted?
url visitc
-------------------------------------
ftp://wba.or.at 2
ftp://wba.or.at/public_html/ 2
http://wba.or.at/ 82
http://wba.or.at/... ...
Updated•12 years ago
|
Whiteboard: [Advo]
Updated•11 years ago
|
Assignee: limi → nobody
Comment 18•6 years ago
|
||
No more useful
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•