Closed Bug 8514 Opened 25 years ago Closed 25 years ago

Changing "ref" should reroot a tree

Categories

(Core Graveyard :: RDF, defect, P3)

Product:
Core Graveyard
Component:
RDF
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: scottputterman, Assigned: waterson)

References

(
URL
)

Details

(Whiteboard: [7.26.1999]waiting for feedback) 

If possible we'd like changing "ref" to reroot a tree.
Status: NEW → ASSIGNED
Target Milestone: M8
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
Closed: 25 years ago
Resolution: --- → FIXED
Fix checked in.
Whiteboard: fix ready to go → [7.26.1999]waiting for feedback
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.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.