Closed Bug 369253 Opened 18 years ago Closed 18 years ago

Rebuild issues in the toolbar view

Categories

(Firefox :: Bookmarks & History, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME
Firefox 3 alpha6

People

(Reporter: asaf, Assigned: dietrich)

References

Details

Attachments

(1 file, 1 obsolete file)

I see some contents-rebuild issues in the toolbar view. 1. Right click in the empty area of the toolbar, choose New Separator/Folder. The expected result is to have the new item appended right after the last item. Toolbar rebuild _is_ triggered at this point, but the new item is only shown the next time the toolbar is constructed (i.e. either in a new browser window, or after invoking toolbar-customization). I would bet that the result node contents are not invalidated as new items are added. 2. _rebuild sometimes adds new items in the wrong order if they've been added from another view (e.g. Places Organizer). Again, the order is fixed the next time the binding is constructed.
Attached patch Query again on each rebuild (obsolete) (deleted) — Splinter Review
So this works, but really shouldn't be necesary
Attached patch Query again on each rebuild (deleted) — Splinter Review
So this works, but really shouldn't be necessary.
Attachment #253935 - Attachment is obsolete: true
Depends on: 366136
Assignee: nobody → dietrich
Blocks: 370099
Status: NEW → ASSIGNED
Target Milestone: Firefox 3 alpha2 → Firefox 3 alpha3
Summary: Rebuild isssues in the toolbar view → Rebuild issues in the toolbar view
I'm not seeing this in current builds. Mano, was this checked in? or did the problem go away due to other incremental-update fixes?
in my debug build from today, on both windows xp and mac os x, on my debug build, I am not seeing issue #1 or #2 in comment #0. asaf, do you still see it? to answer dietrich question in comment #3, according to lxr, asaf's patch did not land. (http://lxr.mozilla.org/seamonkey/source/browser/components/places/content/toolbar.xml#520)
I wonder if neil's work for bug #337868 is responsible for this not being an issue anymore?
It would, yeah, keeping this on the radar though to figure out if we still have a back-end issue here with nsINavBookmarksObserver.
No longer blocks: 370099
Flags: blocking-firefox3?
Target Milestone: Firefox 3 alpha3 → Firefox 3
Flags: blocking-firefox3? → blocking-firefox3+
Target Milestone: Firefox 3 → Firefox 3 alpha6
it's been a month, still not reproduce-able. resolving wfm.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
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.

Attachment

General

Created:
Updated:
Size: