Closed Bug 47319 Opened 24 years ago Closed 23 years ago

TOC button does not work all the time

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

x86
All
defect
Not set
major

Tracking

()

RESOLVED WORKSFORME
mozilla1.0.1

People

(Reporter: hjtoi-bugzilla, Assigned: joki)

References

()

Details

(Keywords: helpwanted, relnote)

Attachments

(1 file)

Clicking the TOC button should open a table of contents on the left. Sometimes
nothing happens when you press the button.

This almost always happens on my NT, never seen on Linux, and occasionally
harishd@netscape.com has been able to reproduce that behaviour on NT.
jrgm@netscape.com has been able to reproduce this as well.

After playing around for a while on NT it usually starts working, sometimes I
need to restart the browser to see that behaviour.
I can now reproduce this on Linux as well. Changing OS to all.

After looking at this in debugger the click event is being created, so it must
get lost somewhere or something else funny is happening.
Status: NEW → ASSIGNED
OS: Windows NT → All
I made a simplified test case, and noticed that adding "javascript:" protocol to
the onclick URL made the thing work. But this still does not explain all,
because when I open the URL it does not work, yet when I open the identical file
on my HD the TOC button works.
I am nominating this for nsbeta3 because of the major functionality loss.

Before attacking this code wise I would need to make a survey, say with 10 
different pleople, to see if they see this problem. If they don't, I would be 
happy to future this. So far I am seeing this almost 100% of the time, and 
harishd saw this a few times.

I am seeing this both on NT and Linux, and doing various tricks I might get it 
to work for a while, after which it will stop working for me.
Severity: normal → major
Keywords: nsbeta3
I get this on mac, linux and win32 (win2k). Sometimes it will work on first 
load, but most times it won't. I put a dump statement in the onclick handler,
and it appears that the event handler is not being called at all when this 
fails to work.
Marking nsbeta3+...
Whiteboard: [nsbeta3+]
I am raising the priority because otherwise this would be dumped, and I believe 
this is severe enough to be a P2. This happens on one of our few XML examples so 
it is quite visible for people interested in XML (provided they happen to be one 
of the unfortunate people that actually experience this).

Taras, I see you joinded the CC list as well, are you seeing this bug?
Priority: P3 → P2
Heikki, I see this *sometimes* using a 14 september build on WinNT. It appears
that, the longer you've been using the browser, the bigger chance you have of
seeing it. A just started Mozilla seems to show+hide the menu fine.
This is driving me nuts... When following this through in the debugger I have 
not found anything out of the ordinary (barring one strangeness, although 
forcing the "correct" code path in the debugger did not help either). 

The JS file gets loaded, click event gets created, and it looks like event 
handlers get called and none of them fail. Still, dumps placed in JS show that 
JS is not being run.

I was creating a minimized testcase, and at one point I noticed the button got 
stuck in down position. This did not affect the behaviour though, so it is 
probably some layout bug.

So what I have come up with for a testcase is:

<?xml version="1.0"?>
<book xmlns:html="http://www.w3.org/1999/xhtml">
 <html:script>
   function createToc() {dump("createToc\n");}
 </html:script>
 <html:input type="button" value="Contents" onclick="createToc();"/>
</book>

This fails on first load for me, on NT. If I reload it, it seems to work after 
that.

I also noticed that if I removed some excess from the testcase, it was working 
more often. But I was still able to reload it so many times that it stopped 
working, and again reload it enough times so that it started working etc.
this is not high visibility user impact problem.  PDT thinks P4.  (lchiang 
using trudelle's account temporarily)
Priority: P2 → P4
Whiteboard: [nsbeta3+] → [nsbeta3+][PDTP4]
This works fine on my machine, but, for some reason, fails on Heikki's.  At this
point, we're minusing this.  Once we figure out what set of conditions cause
this bug, we'll relnote them.
Keywords: relnote
Whiteboard: [nsbeta3+][PDTP4] → [nsbeta3-][PDTP4]
Updating QA Contact.
QA Contact: janc → lorca
*** Bug 54622 has been marked as a duplicate of this bug. ***
Adding this to this bug, instead of to bug 54622, which was a dupe.

Under Mozilla build 2000100208-M18 under Mac OS 9.0.4, I was unable to get the
"Contents" button to pop the table up.  Click on button -- nothing happened.
Got the button to work *once* after reloading the page in Modern theme, but
button wouldn't work at all in Classic theme.

Additional note:  I found this while testing bug #40646.
Copied from Bug #54622 just for info:

Under certain circumstances, when I'm using the classic skin, the Contents
button on the XML IRS demo doesn't do anything. No sidebar with the Table of
Contents; no messages to console.

Judging by the steps to reproduce (see below), this seems to have something to
do with the way the browser window is created. However, the output to console
looks the same regardless of which method I use to create the window.

I haven't been able to reproduce this bug with the modern skin.                                                 

Reproducible: Always
Steps to Reproduce:
1. Open Mozilla.
2. Select the classic skin.
3. Select Debug > Viewer Demos > #15 XML IRS.
4. Click the "Contents" button. Nothing happens.
5. Open a new window by selecting File > New Navigator Window.
6. Repeat steps 3 and 4 in the new window. Nothing happens.
7. Close the new window.
8. Open a new window by clicking the ship's wheel icon in the lower left corner
of the browser window.
9. Repeat steps 3 and 4 in the new window. The Table of Contents sidebar opens.

Actual Results:  The Contents button only works if the window is created by
clicking the ship's wheel icon.

Expected Results:  The Contents button should work regardless of how the window
is created.
Future.
Target Milestone: --- → Future
relnote-devel, but it's not at all clear exactly what the relnote should say... 
can someone clarify?

Gerv
Whiteboard: [nsbeta3-][PDTP4] → [nsbeta3-][PDTP4] relnote-devel
This is relnote-user, not devel. There is nothing the developer can do in this
case that I know of. For some users this works always, for some others it
usually does not work. This is not a generic HTML-button-does-not-work-in-XML
bug because the buttons in other samples work just fine. There is just some
strange combination in this sample that breaks...
Whiteboard: [nsbeta3-][PDTP4] relnote-devel → [nsbeta3-][PDTP4] relnote-user
Target Milestone: Future → mozilla0.9
Target Milestone: mozilla0.9 → mozilla0.9.1
Changing Status for my reference.  Was NSBETA3-.  Anyone think this 
should be renominated?
Whiteboard: [nsbeta3-][PDTP4] relnote-user → [nsbetadenied][PDTP4] relnote-user
I'm sure heikki wants to fix this. (I want him to :-]
Keywords: nsbeta3nsbeta1
Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok
Tom, I think this really is an event bug. I have not been able to track down why
this happens. As far as I can see, everything is working correctly. So it is as
if the click event disappears somewhere, or nobody is acting on it. I can
reproduce this almost 100% (which makes some web applications totally unusable
to me), harishd, jrgm and trudelle etc. have also seen this. For others things
work just fine. If you can spare any insights it would be great...
No longer depends on: 79836
Target Milestone: mozilla0.9.1 → mozilla0.9.2
QA contact updated
QA Contact: gerardok → madhur
Target Milestone: mozilla0.9.2 → mozilla0.9.3
I am no longer able to reproduce this since I got a new computer. Since this
really is an event bug, reassigning to joki. If someone can still hit this one,
holler out please...
Assignee: heikki → joki
Status: ASSIGNED → NEW
Priority: P4 → --
Target Milestone: mozilla0.9.3 → ---
Well, *this* is interesting: On Win98, build 2001061304, when I click the 
Contents button, it opens the Table of Contents pane--but it doesn't reflow the 
page. The Table of Contents pane acts like an overlay. I couldn't get the page 
to reflow at all, even when I resized the window.

I'll attach a screenshot momentarily. Changing status to ASSIGNED.
Status: NEW → ASSIGNED
I'm seeing this too with build 2001062211 on Win2k (SP2).

Actually, I've been seeing it for a few days, but hadn't gotten around to seeing
if the behavior was reported or not until now.

Jake
I reported bug 87485 for this behavior.  Also attached a testcase showing what
is going on.  DOM styles are changed, but not realized in layout.

jake

*** This bug has been marked as a duplicate of 87485 ***
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
No, this is not a dupe of bug 87485. This bug is about nothing happening when
you click the TOC button in the URL testcase. If you see the TOC appearing you
are not affected by this bug. My experience earlier was that something like 20%
of users saw this at least occasionally.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Status: REOPENED → ASSIGNED
we need a boiled down test case here.
Target Milestone: --- → mozilla1.0.1
Removing adequated PDT grafitti.  
Whiteboard: [nsbetadenied][PDTP4] relnote-user
Tried to reproduce with build 2001101202 (Linux) but the TOC button seems to
work fine,
other than being just a bit sluggish (PIII 450 Mhz with 512 Mb RAM). Browser was
open quite a long time (> 1 hour).
I'm not able to reproduce with a recent Linux build, either.
Ok, let's hope this is now a goner, haven't been able to reproduce this either
in a while.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → WORKSFORME
QA Contact: madhur → rakeshmishra
QA Contact: rakeshmishra → trix
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: