Changing "ref" should reroot a tree

VERIFIED FIXED in M9

Status

()

Core
RDF
P3
normal
VERIFIED FIXED
19 years ago
19 years ago

People

(Reporter: scottputterman, Assigned: Chris Waterson)

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [7.26.1999]waiting for feedback, URL)

(Reporter)

Description

19 years ago
If possible we'd like changing "ref" to reroot a tree.
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M8
(Assignee)

Updated

19 years ago
Whiteboard: implemented; getting (benign?) asserts in table code
(Assignee)

Comment 1

19 years ago
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).

Comment 2

19 years ago
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.
(Assignee)

Comment 3

19 years ago
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.)
(Assignee)

Updated

19 years ago
Whiteboard: implemented; getting (benign?) asserts in table code → fix ready to go
(Assignee)

Comment 4

19 years ago
Screw the asserts. This code is ready, baby.

Comment 5

19 years ago
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?
(Assignee)

Comment 6

19 years ago
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.

Comment 7

19 years ago
I understand.  Please include me in the Cc on the new bug.  I will switch over,
but not until we can function without asserts.
(Assignee)

Comment 8

19 years ago
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...
(Assignee)

Updated

19 years ago
(Assignee)

Comment 9

19 years ago
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".
(Assignee)

Comment 10

19 years ago
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
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 11

19 years ago
Fix checked in.

Updated

19 years ago
Whiteboard: fix ready to go → [7.26.1999]waiting for feedback

Comment 12

19 years ago
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

Comment 13

19 years ago
marking verified due to discussion with scott.
You need to log in before you can comment on or make changes to this bug.