102792 - JS Menus vanish too soon. related to setTimout/clearTimeout?

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect, P4)

Description

[Prashant Desale]

This bug is generated from Bug# 68488 which is fixed now, but small part of that 
bug still needs to be fixed, hence filing seperate bug for it.

Problem is that with Netscape6 the menus vanish too soon, as though the TimerID 
that governs their scheduled disappearance time is not being cleared when the 
user mouses-over the menu.

For the source file of the menu script, go to:

http://www.atuan.com/ship/scripts/menus.js

For the CSS file:

http://www.atuan.com/ship/scripts/ship.css

STEPS TO REPRODUCE:
1.  Go to http://www.atuan.com/ship/index-beta4.html

2.  Move your mouse over the link  OIE OR Program and Links to bring up sub-
menus; then move your mouse over the sub menu.  It will vanish after a second 
or so.

Actual Results:  Submenus vanish too soon. [Compare it with NS 4.x or IE] 
[Somehow The TimerID that governs their scheduled disappearance time is not 
being cleared when the user mouses-over the menu.]

Expected Results:  The expected behavior is this:

1) User mouses over parent link; sub-menu is made visible.

2) User moves mouse off of parent link; function HideDelay() called, 
which sets a timeout calling the function that hides sub-menus.

3) If user mouses over visible subment, all pending calls to Hide() are 
cancelled, thereby extending the visibility of the sub-menu.

4) If user moves mouse off of sub-menu, HideDelay() is called again so that the 
sub-menu will vanish once it's no longer necessary.


The HTML includes a layer tag for onMouseOver/Out recognition in NS 4.x 
browsers, but that shouldn't affect Netscape 6, as it simply ignores the layer 
tag.  For IE and Netscape 6, duplicate MouseOver/Out events are put into the 
table tag that defines the sub menu instead, and the whole thing is encapsulated 
in a div tag which defines the sub-menus ID, position information, and 
visibility.

Comment 1

[Prashant Desale]

Severity = LOW [No Crash, No severe functional failure, Results in Cosmetic 
failure]
Visibility = MEDIUM [Real world website usage, Gets one point of 
compatibility with other browsers since it works on other browsers. gets one 
more point on compliance with adopted techonology, that is JS] 

Priority = Visibility * Severity

Priority = p4

adding word "qawanted" because I'm setting this priority on available data & if 
someone feels otherwise then please investigate this more & feel free to change 
this priority.

Comment 2

[Will Martin]

All right.  I originally reported bug 68488, which spawned this one.  It's been
a long time, but I finally got around to doing some more testing.

As noted, I originally thought the problem was that the timer that governs the
scheduled disappearance of certain DIV tags was not being cleared.  However,
when I put together a page to test the setTimeout and clearTimeout functions, it
worked perfectly.  (That page is available at
http://www.atuan.com/ship/moztest/index.html -- it's somewhat schlocky, but did
its job.)

The only other thing I could think of that might be causing the original script
not to work as expected was the presence of a LAYER tag bearing identical
onMouseOver/Out event handlers.  It's there for backwards compatibility with NS
4.x.  So I put together a page testing the onMouseOver/onMouseOut events with
variety of configurations similar to the one in the original script.  (This
second page is at: http://www.atuan.com/ship/moztest/mousing.html and is more
important and less cutesy than the first one.)

A menu area in the original script consists of three main tags: a DIV, a LAYER,
and a TABLE.  The DIV and LAYER tags contain the mouse event triggers that make
the script run, with the Layer for NS 4.x as noted above.  The table ordinarily
does not bear onMouseOver or Out events.  The test page consists of seven areas
using various combinations of these tags, to whit: 

   1) DIV/LAYER/TABLE (as a control)
   2) DIV/TABLE but no LAYER
   3) LAYER/TABLE but no DIV
   4) DIV/LAYER but no TABLE
   5) TABLE only (with onMouseOver / Out events added to the TABLE tag)
   6) DIV only
   7) LAYER only

When you mouse over one of these areas, the function Cancel() is called, which
clears any existing timers.  Cancel() also changes a bit of text at the bottom
to tell you the status of the timer, in this case using the phrase "Timer should
be cleared now."  

When you mouse out, a timer is set with a timeout value of 3000 milliseconds,
and the timer status text changes to "Timer set."  If the timer expires without
being cleared, it pops up an alert box saying so.  

All of the areas work the way they are supposed to, EXCEPT for the ones that
have both a LAYER tag and a DIV tag with onMouseOver onMouseOut event handlers.
 Those don't work as expected.  For example, try mousing over the control, at
the top, that has all three tags (DIV, LAYER, TABLE).  Don't mouse out, just
leave the cursor on it.  Theoretically, nothing should happen, since the timer
is not supposed to be set until you mouse *out* of the area.  However, that is
not the case.  If you mouse in but not out of area #1, after a few seconds you
will get an alert saying that the timer expired without being cleared.  In fact,
you'll get not one but several of those messages.  Since the timer is not even
supposed to have been seen, this behavior is most suspicious.  (Try this on area
#4, it works there to, but it's harder to hit because the mouse/over/out area is
less well defined visually, lacking the bordered table.)

My theory is that Mozilla is recognizing the onMouseOver and Out events that are
on the LAYER tag in addition to the ones on the DIV tag.  It mouses over the
LAYER, then out of the LAYER and into the DIV, thereby setting a timer that
expires even though it's not supposed to have been set.  I am at a loss to
explain the multiple timers that appear when you just leave the mouse over the
area.  (I've seen as many as five timeout alerts pop up.)

This is strange, since LAYER is a non-standard tag intruduced by Netscape well
before it got Open Sourced.  I suppose this could be a legacy of the original
Netscape code, but I was under the impression that Mozilla's code has basically
been rewritten from the ground up, and that it only supports W3C standard tags.
 Isn't it supposed to simply ignore tags that it doesn't understand, and all of
their attributes as well?

Some further notes:

I've tested this page with two builds (both under Win32; my Linux versions are
always custom-compiled, so no build numbers).  The first is the official 0.9.9
build.  The second is the most recent nightly I could find, with build ID
2002041210.  

When you mouse over but not out of one of the trouble areas, as many as five
alert boxes will pop up.  Sometimes, when you click "OK" on the last of those
five, the browser will maximize whatever programs is one to the left in the
Windows task bar instead of returning to its normal state.  Also, sometimes
(under circumstances I haven't pegged down exactly) Mozilla will pop up a couple
of alert boxes and then the top of the Mozilla window and its button on the
start bar will flash alternately blue and grey until you dismiss the alert boxes
with the okay button.

On an unrelated note, it appears that the mouse over/out zone for each area
containing a DIV tag extends all the way to the extreme right of the screen, and
not just around the TABLE, LAYER, or text that is actually contained in the DIV.
 What's up with that?

Finally, at one point during testing, the 0.9.9 build actually crashed on me. 
Talkback ID #TB5141458Z.

I expect I could probably make the original script that brought the issue up
work properly by including a routine that uses document.writeln() to write in
the LAYER tags for NS 4.x browsers only.  I will probably do this.  However, it
is something of a kludgy workaround.  I'd rather get it fixed in Mozilla if
possible.

Thanks, and I hope that wasn't information overload.

Comment 3

[Bob Clary [:bc] (inactive)]

see bug 136527 for a related case.

Comment 4

[Jay Patel [:jay]]

Here's Will's crash incident mentioned in comment #2:

 Incident ID 5141458   
Stack Signature  GlobalWindowImpl::DropTimeout 2366da93
Trigger Time 2002-04-12 17:36:06
Email Address [e-mail]
URL visited
Build ID 2002031106
Product ID MozillaBranch
Platform
Operating System Win32
Module
Trigger Reason Access violation
User Comments Crashed while working on a test-page related to Bugzilla Bug
#102792. Crash was unexpected; will mention in report on Bugzilla.
Stack Trace
GlobalWindowImpl::DropTimeout
[d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 4271]
GlobalWindowImpl::TimerCallback
[d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 4438]
nsTimerImpl::Process [d:\builds\seamonkey\mozilla\xpcom\threads\nsTimerImpl.cpp,
line 330]
PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 591]
PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c,
line 524]
_md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line
1072]
KERNEL32.DLL + 0x24407 (0xbff94407)
0x00648c16 

Don't know if that helps at all, but it can't hurt to know if his testing led to
come crash.

Comment 5

[Will Martin]

Attachment: Test case demonstrating window flashing and switching

I've been doing a bit more testing.  This is still a problem in RC3 under Win32
(98 SE, build ID 2002052306).  In fact, one of the behaviors I mentioned in
comment 2 has become more noticeable.  I've attached a test case to the bug.

If you mouse over the test area (which contains LAYER and DIV tags with
duplicate onMouseOver/Out events), the browser's title bar and icon on the
start bar will flash alternately blue and grey until you clear the five alerts
that pop up.  When the final alert is cleared, the focus will switch to another
application, if you have another one running.  If you have an application whose
start bar icon is to the left of Mozilla's, it will switch to that application;
otherwise it will switch to the right.	Furthermore, there seems to be a bias
towards Mozilla itself; it prefers to switch the focus to other instances of
Mozilla.  So, suppose you have three programs running: Mozilla, Notepad, and a
second copy of Mozilla.  If you hit this bug in Mozilla #2, it will switch the
focus to Mozilla #1, skipping Notepad.	If you hit it in Mozilla #1, it will
switch to Mozilla #2, skipping Notepad.

If you hit this bug with only one copy of Mozilla going, it will switch to the
application one to its left in the start bar; or, if there is no program to its
left, it will switch one to its right in the start bar.  If Mozilla is the only
application running when you hit this bug, nothing of note happens.

Sometimes, programs that receive the focus as a result of this bug will
maximize and come to the front of the screen, in effect becoming the current
working program.  However, I have also seen programs receive the focus (ie
their button on the start bar became selected) but not maximize; instead they
remained hidden behind Mozilla.

The super-long DIV issue (see bug 136527) is still there.

This is a really weird bug.

On a related note, I was in fact able to make the pop-up script that started
this whole thing work properly by using document.write() to insert LAYER tags
for NS 4.x and no other browsers.  I remain hopeful that this will get fixed in
Mozilla, as it adds needless complexity to the script.

Thanks!

Comment 6

[Harshal Pradhan]

Will, 

Your testcases seem to be working fine for me with mozilla1.2 beta and current
trunk (Though I still see the problem with moz1.0.1)

This seems to have got fixed since that time. Can you please check with a more
recent build and confirm that?

Comment 7

[Will Martin]

Well, you're right.  It does seem to function properly now; I've just tested
both my testcases and the original script that caused the problem in Phoenix 0.4
and with a recent nightly -- 2002112304 -- and everything is working the way it
ought to be.  I plan to leave my NS4 workaround in place until the 1.0.x branch
works properly, since that's my development target.

Good to see the magic of open-source at work!

Comment 8

[Harshal Pradhan]

Well, at this stage I think only crashes/security stuff is even being considered
 on the 1.0.x branch. Since this appears to work as expected on trunk, the
chances that anyone will do anything more about this bug are very remote. I'm
marking WFM.