onItem* notifications are dispatched for closed containers (was: lots of assertions ("Removing item we don't have" and "Invalid index for item adding") when I reload a live bookmark and the bookmark organizer window is open)

RESOLVED FIXED in Firefox 3 beta1

Status

()

P2
normal
RESOLVED FIXED
12 years ago
9 years ago

People

(Reporter: moco, Assigned: mano)

Tracking

Trunk
Firefox 3 beta1
Points:
---
Bug Flags:
blocking-firefox3 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

lots of assertions when I reload a live bookmark and the bookmark organizer window is open:

I'm getting a lot of these:

###!!! ASSERTION: Removing item we don't have: 'Not Reached', file c:/builds/tru
nk/mozilla/toolkit/components/places/src/nsNavHistoryResult.cpp, line 3110

followed by a lot of these:

###!!! ASSERTION: Invalid index for item adding: greater than count: 'Not Reache
d', file c:/builds/trunk/mozilla/toolkit/components/places/src/nsNavHistoryResul
t.cpp, line 3038

steps to reproduce:

1) create a new profile
2) open the bm manager window
3) right click on the "latest headlines" rss feed and do "reload live bookmark"

I'm using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070615 Minefield/3.0a6pre

[note, I see this with and without the fix for bug #383572]
Summary: lots of assertions when I reload a live bookmark and the bookmark organizer window is open → lots of assertions ("Removing item we don't have" and "Invalid index for item adding") when I reload a live bookmark and the bookmark organizer window is open
Morphing a bit, this is also the cause for various random front-end assertions.
Summary: lots of assertions ("Removing item we don't have" and "Invalid index for item adding") when I reload a live bookmark and the bookmark organizer window is open → onItem* notifications are dispatched for closed containers (was: lots of assertions ("Removing item we don't have" and "Invalid index for item adding") when I reload a live bookmark and the bookmark organizer window is open)
So, to summarize:
  1. The contents of a bm folder is built once containerOpen = true is set on the
     container.
  2. The contents are _not_ destroyed when the container is closed, unlike
     complex queries, thus the bookmark observers are still set as well. This is
     all by design since incremental update for simple folder result nodes is
     cheap.
  1. Only one view->Item...() caller in nsNavHistoryFolderResultNode has that in
     mind.
Assignee: nobody → mano
Target Milestone: --- → Firefox 3 beta1
Target Milestone: Firefox 3 M7 → Firefox 3 M8
Target Milestone: Firefox 3 M8 → Firefox 3 M9
Flags: blocking-firefox3?
Comment on attachment 281078 [details] [diff] [review]
patch

r=me, thanks
Attachment #281078 - Flags: review?(dietrich) → review+
Attachment #281078 - Flags: approval1.9? → approval1.9+
mozilla/toolkit/components/places/src/nsNavHistoryResult.cpp 1.114
Status: NEW → RESOLVED
Last Resolved: 11 years ago
OS: Windows XP → All
Priority: -- → P2
Hardware: PC → All
Resolution: --- → FIXED
Flags: blocking-firefox3? → blocking-firefox3+
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
You need to log in before you can comment on or make changes to this bug.