672429 - Deleting Browser History (Ctrl+H) is Fubar'd, Deleting Far More then Wanted

Status: RESOLVED DUPLICATE of bug 660543

(SeaMonkey :: General, defect)

Description

[therube]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110706 Firefox/5.0 SeaMonkey/2.2
Build ID: 20110706120824

Steps to reproduce:

 
1. create a new Profile
2. copy existing places.sqlite, one with some extensive history, into the new Profile
3. start SeaMonkey
4. open History (Ctrl+H or via the sidebar)
5. highlight one of the "Title" selections (such as "Older then 6 Months, or some earlier month, like April)
6. hit the Del key
 


Actual results:

 
in 5., if the Title selector is not expanded, then it appears nothing (silently) happens when you hit the Del key

in 5., if the Title selector is expanded, Armageddon!  Who knows what will happen? At most ALL browsing history will be deleted.  Seemingly at best all but one of the Title selectors (usually Today?) will remain.
 


Expected results:

  
Silently failing is not nice.  (Actually what I think is happening is that when a Title selector is not expanded, even though it may "show" as highlighted, focus is not really there?)

A confirmation prompt would be nice.  Perhaps not on a single history item deletion, but on any kind of multiple item deletion, there should be confirmation.

Deleting All or virtually All of your history kind of stinks.
 
 
Error Console shows:

Error: An error occurred updating the placesCmd_open command: [Exception... "'Illegal value' when calling method: [nsINavHistoryResultTreeViewer::nodeForTreeIndex]"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: chrome://communicator/content/history/tree.xml :: get_selectedNode :: line 234"  data: no]
Source File: chrome://global/content/globalOverlay.js
Line: 86
 
 
With line: 86 being:     aCommand + " command: " + e);
 
 
The same places.sqlite copied into FF 5.0 (& deleted through the sidebar - is there any other way) /appears/ to work correctly.
 
 
SeaMonkey 2.0.x (somewhat) similarly seems to be messed up, but as backwards compatibility of places.sqlite is lost kind of hard to compare apples to apples.

SeaMonkey 2.1 looks to behave like 2.2, down to & including the same exact Error Console message.
 
 
Searching, there appear to be similar Bugs, but what I saw tended to be focusing on "sync".  (Sync has not seen any of my Profiles.)
 
 
Gut feeling says there could be similar issues with much relating to deletions from places.sqlite (including, say, bookmarks).
 
 
If this is a (particular) record (error) entry in places.sqlite that happens to be causing this, it is inexcusable that there is no built-in or readily available method to 1) verify the data in places.sqlite 2) dump the data such that invalid entries can be targeted & excised 3) an ability to import "cleaned" data back into places.sqlite.

Comment 1

[therube]

Thinking about this, this may be due to the way History, by default is Grouped -  by Day.

Appears a "Day" grouping causes overlaps, such that "Older then 6 months" may very well encompass everything, such that All ends up getting deleted.

A "Day" grouping does not differentiate between a (particular) URL visited 6 months ago & one visited today.

Such that if you were to find the entry: https://bugzilla.mozilla.org/ in the 6 month category, one (I) would expect that deleting that would delete all "https://bugzilla.mozilla.org/" 6 months of age or older, but instead what happens is that all "https://bugzilla.mozilla.org/" are deleted, regardless of when visited.

So if you have visiting https://bugzilla.mozilla.org/ a total of 999 times, & of those 999 times, 18 were today, & 981 times were from 6 months or more ago (extended vacation), if you deleted the "Older then 6 months" grouping, & since https://bugzilla.mozilla.org/ is included in that grouping, all 999 entries are deleted, not just the 981 from that time period.

So deletions are based upon URI & not any specific grouping that may be displaying.

Given the default grouping this is just crazy.  Totally illogical.

So the most you can do (with a "Day" type grouping, or by using a filtered search) is to delete a URI (website) or extended set of same (domain) with no method to select a From/To range.

Looks like if you were to 'Group by None', then sort by 'Last Visited' then you can relatively easily select some range of time to delete, & I believe that should work out OK?

There may be a refresh issue (as in like it is not) associated.
And have you ever tried to delete a mass of entries (say 47285 entries) - takes a while ;-)

Anyhow, the way the data is presented to you, by default in particular, gives no clue as to what will happen when you delete an entry.

Comment 2

[therube]

FF 5.0 may be working correctly - at least it works differently.

FF makes it harder to figure out, as their "History" displays only the "Title", not the Location or Last Visited or Count!

Deleting "Older then 6 months" still leaves many "Day" categories & entries within.

https://bugzilla.mozilla.org/ was definitely included in the "Older then 6 months", but whether it still exists (since Older ... was deleted), I'm not sure (FF making it hard to determine).  Plenty of "bugzilla" entries remain when searched, but not sure if "https://bugzilla.mozilla.org/" specifically?  And I'm not sure how to copy entries out from the sidebar (as you can do in SeaMonkey's Ctrl+H)?

Using "MozillaHistoryView" it appears that FF also deleted the "999" instances of https://bugzilla.mozilla.org/.  (Nonetheless, it must be doing "more" right, as deleting the "Older then 6 months" category left substantially more then was left in SeaMonkey?)

http://www.nirsoft.net/utils/mozilla_history_view.html

Comment 3

[David E. Ross]

Is this the same as bug #660543?

Comment 4

[Jeff W]

RELATED:

In History - right click on an entry, and try any of the delete options.  nothing happens, but if you exit/re-enter the browser, the delete appears to have been successful.  This worked properly in 2.2.   Thanks/j

Comment 5

[Jeff W]

(sorry - Comment 4 refers to 2.3.2/2.3.3)

Comment 6

[David E. Ross]

Re comment #4:  This is now bug #686326.

Comment 7

[therube]

DUP Bug 660543 - When Trying to Delete Part of History, All History Was Deleted

Marco Bonardo's [:mak] comments there look to describe what is happening well, even if methodology/UX is highly flawed (IMO).