the tree nodes don't open/close after first time

RESOLVED WORKSFORME

Status

()

Core
Layout
P3
normal
RESOLVED WORKSFORME
18 years ago
17 years ago

People

(Reporter: schmeic, Assigned: Kevin McCluskey (gone))

Tracking

Trunk
Future
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: invalid?, URL)

(Reporter)

Description

18 years ago
From Bugzilla Helper:
User-Agent: Mozilla/4.72 [en] (X11; U; Linux 2.2.12-32 i686)
BuildID:    2000080712

clicking on a node the first time will expand it.  after that, clicking on nodes
has no effect.

Reproducible: Always
Steps to Reproduce:
1. click on tree nodes.
2.
3.

Actual Results:  nothing after the first click.								

Expected Results:  the tree should collapse or expand.							

This works nicely in both Netscape 4 and IE 5.

Comment 1

18 years ago
Using Mozilla tip builds 2000-08-21 on WinNT, Linux. 
Confirming bug.

On Linux: a tree node will only collapse/expand once
On WinNT: a tree node will collapse/expand several times, but once you 
          move to another node, that one will collapse/expand only once 

No errors are indicated in the JavaScript Console.
In the debug console, I see the following:  

On Linux: no messages whatsoever when I click any tree node
On WinNT: when the collapse/expand is working, I see (twice): 

                     Enabling Quirk StyleSheet

          when the collapse/expand fails for the first time, I see (twice):

                     WARNING: not supported for views, 
                     file d:\mozilla\view\src\nsScrollPortView.cpp, line 98

From then on, the collapse/expand does not work at all, and no more messages
are seen in the debug console -

Reassigning to XPToolkit/Widgets: Trees -
Assignee: rogerl → hyatt
Status: UNCONFIRMED → NEW
Component: Javascript Engine → XP Toolkit/Widgets: Trees
Ever confirmed: true
QA Contact: pschwartau → jrgm

Comment 2

18 years ago
Well, this is an html document that implements a tree in DHTML, so it's Layout
not XPToolkit/Trees. However, looking in the frame source code, I see the classic
'if {document.layers) {} else if (document.all) {}', which is a pretty fair
indication that this bug is INVALID (not a bug, since document.(layers|all) do
not exist as part of the W3C DOM. 
Assignee: hyatt → clayton
Component: XP Toolkit/Widgets: Trees → Layout
QA Contact: jrgm → petersen
Whiteboard: invalid? [Layer]

Comment 3

18 years ago
Hmm, seamonkey didn't submit my whiteboard comment with the rest of the changes
(weird ...). Adding it now ...
Component: Layout → XP Toolkit/Widgets: Trees
QA Contact: petersen → jrgm
Whiteboard: invalid? [Layer] → invalid?

Comment 4

18 years ago
[*&@#& what is up with the form submission. Resetting some other values that
got stomped on. Sorry for the spam, but eating dogfood is not always perfect :-]
Component: XP Toolkit/Widgets: Trees → Layout
QA Contact: jrgm → petersen

Comment 5

18 years ago
In principle, it is perfectly alright to do 

           if (document.layers)
           if (document.all)

Many pages sniff for the browser this way. Leaving out the
"if"'s would be the classic mistake making the bug invalid.

It may be that the author of the page goofed up in that both
the above expressions will evaluate to False in Mozilla, 
but that will require further analysis. 

An interesting question is, Why is Mozilla's behavior so different here
on WinNT and Linux? Why is it that on WinNT, a node will open and close 
just fine, and not malfunction until you move to another node? 

Why do we get the message 

           WARNING: not supported for views, 
           file d:\mozilla\view\src\nsScrollPortView.cpp, line 98

when the malfunction occurs?
(Assignee)

Comment 6

18 years ago
Dividing up claytons bugs to triage.
Assignee: clayton → kmcclusk
(Assignee)

Comment 7

18 years ago
This bug has been marked "future" because the original netscape engineer working
on this is over-burdened. If you feel this is an error, that you or another
known resource will be working on this bug,or if it blocks your work in some way
-- please attach your concern to the bug for reconsideration.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
(Assignee)

Comment 8

17 years ago
Works fine for me with trunk build on Linux 10/9/2001 build.
Marking WFM.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.