Closed Bug 30578 Opened 20 years ago Closed 20 years ago
onmouseout not firing when leaving frame
The onmouseover effects on the "about" "sites" and "help" menu items in the top.html frame eventually stick at one color after you move over the three items several times. M14 Talkback build.
I'm not seeing this on Linux build 2000.03.09.13. Can you check with a recent build?
Assignee: rogerl → vidur
QA Contact: rginda → desale
Ok, I think I know what's going on. When you mouse over one of the links and then move the mouse down, the mouseover effect sticks. The reason seems to be that the mousout event never fires, because when you leave the table cell that has the onmosueover handler, you're already in a different frame. Changing summary, giving to HTML Frames.
Assignee: vidur → pollmann
Component: DOM Level 0 → HTMLFrames
QA Contact: desale → petersen
Summary: onmouseover effects sticking. → onmouseover not firing when leaving frame
I played with the testcase for a few minutes and could not get the image to stick. This is also what I observed when I opened the top frame of the original page in its own window. If I understand you correctly, what you're seeing is that at some point, the image "sticks" no matter what you do. That I don't see, however. By mousing over the image and then moving the cursor to the right, I can always get the "inactive" picture to redisplay.
I think you've understood correctly what happens. The word "help" turns white and stays white from then on out. I'm not sure what causes it--it appears to be a timing problem of some kind. Sometimes it will do it right off, sometimes it takes 20 passes. For a while, I could be pretty much guaranteed of it if I left the image downward (in the testcase as well as the original page, so it wasn't a frames thing). It doesn't appear to be related to how fast one enters or leaves or reenters the box, either. In fact, when it was dependably showing up, it was always, so far as I can remember, on a clean exit, not on a quick exit-reentry sequence. Of course, it could've been on the previous exit and reentry, as one would not notice it until the following exit.
Ok, then we have two bugs here. One I can reproduce: if an image with an onmouseout handler overlaps a frame border, and the cursor moves away from the image into another frame, the onmouseout event never fires. This is what I can reproduce on the page pointed to by email@example.com: 1. Go to http://www.zeldman.com/about/aboutf.html 2. Mouse over one of the links in the upper right corner (say, the "sites" link) and see image change to white 3. Move mouse downward into the central frame Actual result: image stays white Expected result: image should change back to grey text The image will change back to grey if you mouseover and then move the cursor away from the image sideways, in the same frame. firstname.lastname@example.org sees a different bug, where in some circumstances, the image never changes back. I haven't seen that. email@example.com, have you? Anyways, that would be another bug. ashted, can you figure out what makes it happen? maybe provide a set of steps to reproduce it? and file it in a separate bug?
Summary: onmouseover not firing when leaving frame → onmouseout not firing when leaving frame
Moving in from the sidebar or the menubar seems to be involved in it happening. I've created bug 31788 with a slightly different testcase--one which shows that onmouseout is continuing to get called.
I see a similar thing happening when moving from the testcase image to the sidebar, but here, like in the case of moving the mouse to a different frame, I see no mousout firing. CC: joki
I think I'm seeing the same thing you are, and if so, 31788 is a different bug because the mouseout does fire even on the first failure, I think that in the 31788 bug, the failure is that theObj = eval(MM_swapImage.arguments[(navigator.appName == 'Netscape')?i:i+1]) returns null sometimes when it oughtn't.
The string "Netscape" for appName is defined on the stack in NavigatorImpl::GetAppName it should be a static string. Its possible that a pointer fault elsewhere could break this. I'm still seeing this general rollover problem at a variety of rates depending on the speed of the machine. On a 400MHz K6 3D on Windows 2000 it happens less frequently than on a 333 running 98. Its seems more likely to happen running over the border of a frame into a table element than running along the row of table elements, but it still happens in the latter cases, especially at the beginning and end of the rows. Running back and forth on a row of table elements with 'on' and 'off' images will eventually have them all stick to the 'on' image. Because they rarely if ever revert back to the correct behaviour its unlikely to be an event handler problem unless its become tied to the actual table element somehow, rather the overwriting of the image in the table array or the confusion of the indexes of the table seems more likely. This, btw, is with the current BETA branch as well as open source mozilla, as of this morning (21/3/2000)
This has to be related to bug 28858. Would fixing that bug not fix this one?
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.
Target Milestone: M18 → Future
This seems to be fixed. M14 was a long time ago, not really surprising.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Verified fixed in the 2001010408 build.
Status: RESOLVED → VERIFIED
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.