Closed
Bug 1347652
Opened 8 years ago
Closed 6 years ago
Deleting history items grouped by date deletes entire history
Categories
(SeaMonkey :: Bookmarks & History, defect)
Tracking
(seamonkey2.49esr wontfix, seamonkey2.57esr fixed)
RESOLVED
DUPLICATE
of bug 1378089
People
(Reporter: frg, Unassigned)
References
(Blocks 1 open bug)
Details
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
Reporter | ||
Updated•8 years ago
|
Blocks: 2.49BulkMalfunctions
Reporter | ||
Updated•8 years ago
|
Blocks: 2.50BulkMalfunctions
Reporter | ||
Updated•8 years ago
|
Blocks: 2.51BulkMalfunctions
Reporter | ||
Updated•8 years ago
|
Blocks: 2.52BulkMalfunctions
Comment 1•8 years ago
|
||
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
Comment 2•8 years ago
|
||
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)
Comment 4•8 years ago
|
||
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.
Reporter | ||
Comment 5•8 years ago
|
||
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.
Reporter | ||
Comment 6•8 years ago
|
||
Btw. still works in Firefox 53 so it should be possible to unbreak it.
Comment 7•8 years ago
|
||
(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
Closed: 8 years ago
Resolution: --- → INVALID
Comment 8•8 years ago
|
||
(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 → ---
Comment 9•8 years ago
|
||
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.
Reporter | ||
Updated•7 years ago
|
Blocks: 2.53BulkMalfunctions
Reporter | ||
Updated•7 years ago
|
Blocks: 2.55BulkMalfunctions
Reporter | ||
Updated•7 years ago
|
Blocks: 2.56BulkMalfunctions
Reporter | ||
Updated•7 years ago
|
Status: REOPENED → NEW
Reporter | ||
Updated•7 years ago
|
Blocks: 2.57BulkMalfunctions
Reporter | ||
Comment 10•6 years ago
|
||
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
Closed: 8 years ago → 6 years ago
status-seamonkey2.50:
affected → ---
status-seamonkey2.51:
affected → ---
status-seamonkey2.52:
affected → ---
status-seamonkey2.57esr:
--- → fixed
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•