Closed Bug 102792 Opened 19 years ago Closed 18 years ago
JS Menus vanish too soon
. related to set Timout/clear Timeout?
930 bytes, text/html
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.
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.
Priority: -- → P4
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.
see bug 136527 for a related case.
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 firstname.lastname@example.org 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.
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!
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?
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!
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.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.