Open Bug 686326 Opened 13 years ago Updated 2 years ago

When Grouped by None, Deleting History Entries Appears Not To Work But Does Work

Categories

(Toolkit :: Places, defect, P5)

Product:
Toolkit
Component:
Places
Platform:
x86
Windows XP
Type:
defect

Tracking

()

People

(Reporter: david, Unassigned)

References

Details

From the History menu bar, select [View > Group by > None] and [View > Sort by > Last Visited].  Scroll to the bottom of the display.  Select several adjacent entries.  

Press the keyboard Delete button.  Nothing happens.  

Select [Edit > Delete] on the menu bar.  Nothing happens, but the Delete option on the pull-down menu is NOT greyed out.  

This was discovered in an attempt at a work-around for bug #660646, suggested in bug #660543.
It turns out that the deletion only appears not to work.  The entry remains in the History window.  However, when I terminate my browser and then relaunch it, the entry is indeed deleted.  

Summary updated.
Summary: Cannot Delete History Entries When Grouped by None → When Grouped by None, Deleting History Entries Appears Not To Work But Does Work
it's unclear which version you reproduced the bug in, and if it is a regression from a previous version
Re comment #2:  

Bugzilla used to include my UA string automatically in a new bug report.  I guess the move to obfuscate UA strings and version numbers led the Bugzilla developers to remove that capability.  

I have updated SeaMonkey since I first reported this, but I still see this bug in my current version.  The UA string is 
  Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 SeaMonkey/2.3.3
The deleted entry does not go away after leaving the History window open for an extended period.  On the other hand, selecting  [View > Group by > Day] and then reverting back to [View > Group by > None] does cause the deleted entry to disappear.  

I have not tried it, but merely selecting [View > Group by > Day] might be sufficient.
(In reply to David E. Ross from comment #4)
> I have not tried it, but merely selecting [View > Group by > Day] might be
> sufficient.

Merely clicking on the Last Visited column header to change the sort worked. (I clicked three times to get back to a "descending" Last Visited sorting.)
(In reply to Marco Bonardo [:mak] from comment #2)
> it's unclear which version you reproduced the bug in, and if it is a
> regression from a previous version

It is a regression: works with SM 2.0.14 (on Linux 64-bit at least).
Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20110923 SeaMonkey/2.4

This problem exists when running in Safe Mode (to answer a question in the mozilla.support.seamonkey newsgroup).
This still happens in SeaMonkey 2.6. The problem appears to due to the fact that nsNavHistory::RemovePage is called for deletes of 10 entries or less and that function no longer notifies observers to update the tree view (it did in SeaMonkey 2.0.*).

If the tree view was updated in _removeRowsFromHistory (controller.js) after calling removePage in the for loop then that should fix the problem.
This issue only occurs if group none or a search term is in effect (RESULTS_AS_URI). Using day or site (or both) grouping works so maybe the problem is in nsNavHistory and can't be properly fixed in controller.js.
This bug still occurs in SeaMonkey 2.23, is anything going to be done to address this ?
See Also: → 1347652
Priority: -- → P5
Severity: minor → S4
You need to log in before you can comment on or make changes to this bug.