If possible we'd like changing "ref" to reroot a tree.
Whiteboard: implemented; getting (benign?) asserts in table code
I've implemented this. Hyatt, I need you to come look at some asserts that I'm getting in the table code now (seems like it's trying to compute a rowspan on a treechildren tag with zero kids).
This assert was filed as bug 8901 on 6/25/99 but it is still marked as New so I don't think it has had any attention yet.
No, my assert is different: In nsTableFrame::GetEffectiveRowSpan, NS_PRECONDITION (0<=aRowIndex && aRowIndex<GetRowCount(), "bad row index arg"); aRowIndex == 0, GetRowCount() ==> 0. (Seeing same assert on mailnews account window.)
Whiteboard: implemented; getting (benign?) asserts in table code → fix ready to go
Screw the asserts. This code is ready, baby.
What is meant by "Screw the asserts. This code is ready, baby."? Does this mean that the asserts have been fixed and I should give it a try? Or does this mean that I don't want to use "ref" yet because I will land in the debugger over and over when try to develop mailnews and address book code?
It means if you use this in the tree control, you'll assert, because it removes all the treeitem kids from the treechildren tag. The frame construction code tries to determine the rowspan of zero rows, which triggers a benign (that is, guarded) assert. If you plow through the asserts, stuff works correctly. I'd like to get this in, then open a bug vs. hyatt or karnaze on the rowspan assertions.
I understand. Please include me in the Cc on the new bug. I will switch over, but not until we can function without asserts.
Allright, I backed out my changes and it turns out that the asserts were there _anyway_. I've filed bug 9524 on Hyatt about that. I'm seeing some other noise, right now...
Adding test case. To verify: 1. go to above URL 2. click "Swap Body (bookmarks root/personal toolbar)" several times. Expected behavior: tree widget re-roots itself to bookmarks root and personal toolbar each time. 3. Click "back".
Okay, I've been working on this and it looks like the fix is going to be a bit more involved. I'm going to move to M9 and will check in when the tree opens for M9.
Target Milestone: M8 → M9
Status: ASSIGNED → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → FIXED
Fix checked in.
i'm sorry, chris. on nt4, macos851, and redhat52 i loaded the above url, clicked "Swap Body (bookmarks root/personal toolbar)" once (and then many times) and all the content below the gray 'Name' and 'Url' column headers disappeared. what do you mean by 'reroot'? after each click, stdout toggles between either tree = [object XULTreeElement] body = [object XULElement] currentRef = NC:PersonalToolbarFolder or tree = [object XULTreeElement] body = [object XULElement] currentRef = NC:BookmarksRoot which means something, but should the visible content disappear, or shift around, or remain unchanged? thanks
marking verified due to discussion with scott.
You need to log in before you can comment on or make changes to this bug.