To reproduce: Ctrl-H shows the history window. Select a calender entry with history items. Open the context menu and select "Delete". Instead of only the items under the selected entry the entire history db will be cleared and the following exceptions logged: > Timestamp: 3/15/2017 6:56:59 PM > Error: uncaught exception: 2147942487 > Source File: chrome://communicator/content/history/tree.xml > Line: 204 > Timestamp: 3/15/2017 6:56:59 PM > Error: NS_ERROR_ILLEGAL_VALUE: Illegal value'Illegal value' when calling method: > [nsINavHistoryResultTreeViewer::nodeForTreeIndex] > Source File: chrome://communicator/content/history/tree.xml > Line: 204 > Timestamp: 3/15/2017 6:56:59 PM > Error: An error occurred updating the placesCmd_open command: [Exception... "Illegal value'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 204" data: no] > Source File: chrome://global/content/globalOverlay.js > Line: 89
More or less REPRODUCIBLE with unzipped installer of official en-US SeaMonkey 2.52a1 (NT 6.1; WOW64; rv:55.0) Gecko/20100101 Firefox/55.0 Build 20170311002651 (Default Classic Theme) on German WIN7 64bit. a) Not always complete history will be deleted. a1) during the few tests I did always entire history became deleted if I deleted the oldest group a2) At least in 1 test where I had "Today", an other group and "older than 6 Months" when I deleted the other group in the middle, "Today" and "older than 6 Months" remained, but where empty
b) WIN for now. Some additional strange observations, I don't know whether related: c) I observed a problem to delete “older than 6 Months” (only 1 additionsl group “Today” does exist, I don't know whether that matters) in some cases: As long as no sort arrow in any column heading is visible deletion fails Also clicking “Title” heading 3 times so that sort arrow finally will have dissappeared will not enable deletion. Additional “Title” click for ▲ does not enable deletion. After another click on “Title” heading for ▼ I can delete “older than 6 Months”. But ▼ is not a reliable condition for group deletion ability. This might be something completely different, but I wanted to mentin. Observed with WINDOWS7 – SM: 2.33.1, 2.44 Build 20160608085536, 2.46 Build 20161213183751, 2.48 Build 20161201160950, d) With 2.49a1 Build 20161107002359 in a test profile I had “older than 6 Months”, “October 2016”, “Today”. After some unsuccessful attempts to delete “older than 6 Months”, I rightclicked and deleted “October 2016”, but this deleted “Today” and “older than 6 Months”, “October 2016” remained
OS: Unspecified → Windows
Just throwing some (old) bugs out here for reference in case they have any bearing... https://bugzilla.mozilla.org/show_bug.cgi?id=774168#c12 https://bugzilla.mozilla.org/show_bug.cgi?id=672429 (also see the bugs it was DUP'd to)
Yes, there are several issues with history items deletion, I can't tell whether they have a common root (or even are DUPs) or not.
I used it occasionally and it always worked. I suspect a recent change in Gecko broke it. Will see if I find some time this weekend to nail it down to a specific bug.
Btw. still works in Firefox 53 so it should be possible to unbreak it.
(In reply to Frank-Rainer Grahl from comment #0) > To reproduce: > > Ctrl-H shows the history window. Select a calender entry with history items. > Open the context menu and select "Delete". > > Instead of only the items under the selected entry the entire history db > will be cleared and the following exceptions logged: Apart from the exception, this is the intended behavior. removing from history is considered a privacy operation, and as such removing an url is global for the whole history. Removing only certain entries wouldn't make sense from a privacy point of view, and there are better tools for that (Clear recent history for recent history or Expire history by days add-on for old history).
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → INVALID
(In reply to Marco Bonardo [::mak] from comment #7) Currently this one is not INVALID. e) If a user selects some items and presses <del> he expects to delete exactly what he selected and not the whole History. e1) The complained behavior at least will need to be mentioned in Help. Currently SM Help tells: "To delete a single page or folder, select it in the history list and press Delete". This does not match with actual results e2) a warning ("will delete all, are you really really sure?") will be required e3) And so on. f) And the selection behavior should reflect the possibilities. f1) In SM (like in FF) it is possible to select multiple History entries, what is useful to open multiple web pages form History. But nobody will expect that <del> might delete all history f2) I SM (different to FF) it is possible to select multiple history groups, what might be useful to open multiple web pages form History (I doubt). But nobody will expect that <del> will delete all history g) FF seems to drop passwords and so on with deleted History items. We will have to check that for SM, add Help text and so on. h) And: I do not think that deleting all history is an appropriate behavior if only particular folders are selected. If a user wants to delete all history he simply can do <ctrl+a> to select all history (what is different to FF) before he deletes. If we have agreements fo e ... h (may be some else) this Bug might become superfluous or even INVALID. But until then this one at least is a useful META bug for coordination of all required fixes and amendments. BTW: FF 54.0a1 (2017-02-26) (32-bit) does NOT delete all history when I delete "TODAY" folder.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Sorry, first I didn't notice this was seamonkey. I don't take decisions about it, clearly :) Fwiw, in Firefox it works as I said, and it's unlikely to change. So in Firefox, this would be invalid. Sorry for the noise.
After porting the Fx library in bug 1378089 this became a moot point here. The port would need extensive rebasing and l10n changes and so won't make it into 2.49.
Status: NEW → RESOLVED
Last Resolved: a year ago → 6 days ago
status-seamonkey2.49esr: affected → wontfix
status-seamonkey2.50: affected → ---
status-seamonkey2.51: affected → ---
status-seamonkey2.52: affected → ---
status-seamonkey2.57esr: --- → fixed
Resolution: --- → DUPLICATE
Duplicate of bug: 1378089
You need to log in before you can comment on or make changes to this bug.