New issue
Advanced search Search tips

Issue 674637 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Jan 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Omnibar Suggestions occasionally cannot be deleted

Project Member Reported by bswolf@google.com, Dec 15 2016

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.75 Safari/537.36

Steps to reproduce the problem:
1. Type a single letter into the omnibar
2. A suggestion is filled in
3. Hit shift-delete to remove the suggestion

What is the expected behavior?
The suggestion disappears, and doesn't reappear when I type that letter again in a new tab.

What went wrong?
The suggestion is removed from the omnibar, and readded to the list of suggestions. I can scroll to other suggestions and shift-delete them to remove them, but the suggestion that was removed and re-added cannot be removed (shift-delete does nothing while it's selected).

Did this work before? Yes 

Chrome version: 55.0.2883.75  Channel: n/a
OS Version: 
Flash Version: Shockwave Flash 24.0 r0

I am able to reproduce the first half of this (where the suggestion is readded to the list after the initial shift-delete) almost always. The latter half (where the suggestion is unremovable and returns again) I can only reproduce with two non-https websites under different letters. One is the home page of a news site--and Chrome history indicates I read an article on that site yesterday. The other is the host/port of an internal server--history indicates I visited urls on that machine on Dec 1 and Nov 14.
 

Comment 1 by ajha@chromium.org, Dec 16 2016

Components: -UI UI>Browser>Omnibox
Labels: M-55 prestable-55.0.2883.75
Labels: Needs-Feedback
Shift-delete has some caveats:

(1) At least on Windows, but probably also on Linux due to shared code, it's an alias for "cut", so it only "really" requests the suggestion be deleted if there is no selection in the address bar.  In the rare cases I use this, I make sure I arrow down and back up before doing this, which forces there to be no selection.
(2) Not all results are deletable.  Things actually in history can be deleted, but matches synthesized from elsewhere (e.g. if we synthesize a match for "nytimes.com" on the basis of a history entry for "nytimes.com/foo.html") cannot, since it's not safe to delete the history entry for the more specific page in this case, and we don't keep an ever-growing blacklist of the strings we've tried suggesting that the user doesn't like.  (Doing that would have pros and cons, and we think the cons outweigh the pros.)  Similarly, suggestions provided by, say, Google servers cannot be deleted.

A test to see if (2) is the issue here is to use about:omnibox to enter the text in question, click "show all details", and look in the "del" column.  This will have a check or X depending on whether the system can actually delete the underlying result.

My suspicion is that in this case, we're synthesizing potential shorter matches for longer URLs you've visited, and the synthesized matches are not deletable.  Let me know.
Components: Privacy

Comment 4 by bswolf@google.com, Jan 5 2017

Sorry for the delay. Now that I've gone back and checked, my original matches have fallen out of history. Luckily it's reproducible with [a] for accounts.google.com (which is definitely a host I visit to login, but not a URL I visit), and about:omnibox shows it as the top entry for [a] with the following:

Provider	Type	Relevance	Contents	Can Be Default	Starred	Description	URL	Fill Into Edit	Inline Autocompletion	Del	Prev	Tran	Done	Associated Keyword	Keyword	Duplicates
HistoryURL	history-url	901	https://accounts.google.com	✔	✗		https://accounts.google.com/	https://accounts.google.com	ccounts.google.com	✗	✗	1	✔			0

That's a Yes for "Can Be Default" and "Done", and No for "Starred", "Del", and "Prev".

And Additional Info says:
last visit:	12/31/69, 4:00:00 PM
typed count:	0
visit count:	0

I don't quite understand your comment about arrow down and back up to force there to be no selection. The top result ends up the selection always. [a down up] (plus any number of additional ups) results in https://accounts.google.com being the selected option, which cannot be deleted (shift+delete has no effect), while [b down up] resulted in my workstation URL being the selected option, and shift+delete *did* clear it. (Funny enough, now [b] results in an autocomplete entry for badgebuddy.corp while prompting me to hit tab to search buganizer--while the second result is actually a buganizer search.)
Status: WontFix (was: Unconfirmed)
Thanks for the feedback.  There's a good reason the entry for accounts.google.com is not deletable.  You've never been to the particular URL being suggested (https://accounts.google.com)!  You've been to subpages on the site, but you haven't been to the URL itself.  It's not in your history and thus there's nothing to delete in your history.  This is an example of the second entry in comment #2.

This is working as intended.  Please let me know if you have other examples so can investigate to see if they are of the same ilk.

Sign in to add a comment