251912 - Implement a GUI for the deletion of Location Bar entries, akin to CTRL-H.

Status: NEW

(SeaMonkey :: Location Bar, enhancement)

Description

[Jason Bassford]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040716
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040716

We need an easy method of deleting one or more single entries in the Location
Bar.  We can already do this with history with CTRL-H.  Location Bar entries
should have something similar.

Reproducible: Always
Steps to Reproduce:

Comment 1

[Andrew Schultz]

*** This bug has been marked as a duplicate of 157751 ***

Comment 2

[Jason Bassford]

I was wondering why it hadn't been a duplicate of bug 8709 (which I'm also following) as I worked through the various bugs here.  I believe the answer is that both bug 157751 and bug 8709 simply ask for the delete key to work once the dropdown is established.

However, this particular bug is about a full-blown GUI - not part of the actual dropdown.  I'd like to see the location bar entries appear in a window (just like CTRL-H), perhaps with a menu and some more information than just the basic URL.  I had assumed (incorrectly it seems) that my reference to the history window would have made the distinction from simply deleting directly from the location bar drop down list.

Comment 3

[Jason Bassford]

Ah!  And Bug 157751 is about the URL autocomplete, not about the location bar - which is different.

Comment 4

[Jason Bassford]

Argh!  Had meant bug 87098 above.

Comment 5

[Jason Bassford]

I've been thinking about this.  Currently, the entries in the Location Bar are stored in localstore.rdf as:

<RDF:Seq RDF:about="nc:urlbar-history">

There is no information about any of the entries other than the straight URL that was typed in.

On the other hand, URLs that have been visited (by any method) are stored in history.dat and contain a lot more information.

It would make a lot more sense to store the URL bar history in history.dat also - integrating it by simply adding a field that's stored to indicate if the page was visited as a result of typing in the URL directly or not.

Then, the existing history dialog could be modified to allow for views and filters.

In other words, the "visited" view, would sort by all sites visited, and group by day.  However, a "location bar" view, would filter by only those URLs that were visited as a direct result of location bar entry, would sort by date, and would *not* group by day.

A filter / search box would also allow you to bring up the History dialog and start to type in a URL.  The list of places visited would then be narrowed to include only those whose URLs started with what is being entered - in other words, the same kind of mechanism as is used by autocomplete.

In other words, unify history, autocomplete, and location bar history all under a single mechanism that draws its data from the same place.  Different methods of retrieving data (based on filters and different sorts) would be used to get the same results we have currently.  Plus, this would easily solve the problem with this case whereby a GUI (the existing one for History) could be brought up for location bar entries, and also allow for their deletion.

Comment 6

[Andrew Schultz]

the URL dropdown contains everything that was typed in the URL bar.  javascript: URLs, bookmark keywords, etc (except for data: URLs).  These things generally don't belong in history (and they're nice to have in the dropdown).  There's a bug on file to use history to populate the URL bar from history.  Firefox does this, but this makes it harder to sort by order visited (bug 258107 comment 1)