8514 - Changing "ref" should reroot a tree

Status: VERIFIED FIXED

(Core Graveyard :: RDF, defect, P3)

Description

[scottputterman]

If possible we'd like changing "ref" to reroot a tree.

Comment 1

[Chris Waterson]

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

[hangas]

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.

Comment 3

[Chris Waterson]

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.)

Comment 4

[Chris Waterson]

Screw the asserts. This code is ready, baby.

Comment 5

[hangas]

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?

Comment 6

[Chris Waterson]

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

[hangas]

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

Comment 8

[Chris Waterson]

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...

Comment 9

[Chris Waterson]

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".

Comment 10

[Chris Waterson]

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.

Comment 11

[Chris Waterson]

Fix checked in.

Comment 12

[phillip]

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

[phillip]

marking verified due to discussion with scott.