When you delete an item, or even an entire hostname or domain from history, you don't get immediate feedback - instead you have to collapse and re-expand the twisty.. this is bad because it makes it look like delete doesn't work at all! The problem is that the RDF notifications aren't firing for find: URIs - we're correctly unasserting from the history root, but not constructing "likely" find: uris. This MIGHT be a dupe, but I can't find it...

nominating for nsbeta1, 0.9.3, which I think means RTM

nav triage team: Gotta fix this one if we fix anything more for history. Marking nsbeta1+ and mozilla0.9.2

the above fix basically just changes the unassert notifications to a series of three unassert notifications also, I had to move the unassertions BEFORE CutAllColumns() so that we could still retrieve the row value http://lxr.mozilla.org/seamonkey/source/xpfe/components/history/src/nsGlobalHistory.cpp#2915

ok, that isn't quite working... mork appears to be trying hold onto the row during the deletion...

so it turns out that mork was holding a weak reference to the row in the store - so as long as I held a strong referene to it in nsGlobalHistory.cpp, the row appeared to exist in the store. So basically, in addition to the above changes: 1) changed the semantics of FindRow() to always return an error condition when the row is not found, and then updated the callers. Previously, it always returns NS_OK, on success or failure. 2) change FindRow so that after finding the row in the store, that it is in the main table, mTable. No, there is no way to call a FindRow directly on a table. while working on this, I found some slowness in HasAssertion() where we fall back to the GetTargets() case too often.... may help with the history perf bug. this bug works beautifully, and allows the bulk-delete function to remove items from the UI at the time they are deleted.

r/sr = bienvenu

Looks ok to me. sr=waterson

a= asa@mozilla.org for checkin to the trunk. (on behalf of drivers)

yay, fix checked in. thanks all.

I think it'd be mean to reopen this bug but I cannot verify it while bug 11412 is open, so I'll just mark it depends.

VERIFIED Fixed with 2001070503 build