Build ID: 2006-08-01-20 of SeaMonkey trunk under Windows XP. Summary: Selection lost in Download Manager tree view after item is removed from tree. Fallout from either bug 346468 or bug 344085, or something. Steps to Reproduce: 1. Save more than one file. 2. Invoke the Download Manager. 3. Select an item which has another item below it. 4. Click "Remove from List." Expected Results: Next item in the view is selected. Actual Results: Nothing is selected.
Yeah, my bad again. What's happening is that rebuilding the download manager is destroying the frame which disconnects the view from the box object. Now under the old code the view was cached as a property, and the new frame would retrieve the view from the cache and reassociate it with the box object. However the new code does not attempt to reassociate the view until the new frame needs it. Furthermore the old code never returned the cached view if there was no frame.
Created attachment 231745 [details] [diff] [review] Patch version 1 This is the bare minimum to fix this bug.
Created attachment 231747 [details] [diff] [review] Patch version 2 This version more accurately reflects the previous code: * If there was no cached body, and we can't find one, then always return null * If we find a new(er) body, and we have a view, then let the body init * If we have no view, then create one and set it on the body The previous code always asked the body to init; if the body didn't have a view it would then try to find the view on the property and failing that create one.
Fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
Verified FIXED using build 2006-08-03-05 of SeaMonkey trunk (tinderbox build) under Windows XP. Thanks for the quick turnaround, Neil!
Status: RESOLVED → VERIFIED
Component: XP Toolkit/Widgets: Trees → XUL
QA Contact: xptoolkit.trees → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.