Using IMP webmail application. They make extensive use of "onmouseover" and "onmouseout" directives to highlight the email message the mouse is hovering over. With the newest mozilla (0.9.9), the onmouseout events are getting missed - causing several lines on the page to remain highlighted. Machine is a Toshiba Laptop (P3-700, 256 meg ram). This problem did not exist on Moz 0.9.8.

-> Dom Events We need a testcase...

I am having the same problem, and can confirm this. I have not developed a small testcase but you can observe this on an internal site... http://bubblegum/ngdriver/results/results.html This used to work not long ago, so it is a regression.

This seems to be a related issue - When moving the mouse over and out on the top grey box, mouseout only seems to fire on every second expected mouseout event. The second grey box shows some uglier, but possibly related issues with tables and resizing, along with mouseout handling.

This is tested without missed events on: Mozilla/5.0 (X11; U; Linux 2.4.17 i686; en-US; rv:0.9.1) Gecko/20010610 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510 About attachment id=80178: I configrm problem when node.style.overflow is changed 'visible'<->'hidden'. Table cell width grow when node.style.overflow is changed 'visible'<->'hidden'. This is second problem.

*** Bug 137700 has been marked as a duplicate of this bug. ***

better URL from a duplicate

*** Bug 146616 has been marked as a duplicate of this bug. ***

*** Bug 145323 has been marked as a duplicate of this bug. ***

another url: http://www.microsoft.com/germany/

This happens all over the web and is making our gecko qa automation test result page hard to use. Here's another url to reproduce the problem: http://boxfly.free.fr/test2/

This breaks a major AOL Partner site, adidas.com (http://bugscape.netscape.com/show_bug.cgi?id=16554) Marking topembed. Is there any chance to have this for machv/m1.0.1?

Being tracked at http://bugscape.netscape.com/show_bug.cgi?id=16562

*** Bug 152233 has been marked as a duplicate of this bug. ***

topembed+ per EDT triage.

this is a regression from bug 33601 (discovered by backing out patches from ancient CVS) cc'ing Robert O'Callahan

*** Bug 146790 has been marked as a duplicate of this bug. ***

*** Bug 152985 has been marked as a duplicate of this bug. ***

mine

*** Bug 131244 has been marked as a duplicate of this bug. ***

*** Bug 157877 has been marked as a duplicate of this bug. ***

I'm not sure what the bug is here. The first testcase is weird because two elements have the same ID, so it's not really valid. The table testcase seems to work fine as far as I can tell.

for the table, if your mouse hits the text, then the bug will not show up. you might try attachment 87883 [details] from bug 152233. it's simpler to trigger there.

Sorry, I was using the wrong version of Mozilla. I see it now.

What's happening here is that setting the "background" property on the table cell is setting "background-attachment" to "scroll" which causes a FRAMECHANGE to fire in nsCSSParser::AppendValue. There are actually two problems here: 1) The FRAMECHANGE causes the event state manager (I presume) to miss the mouse-out event. Presumably the fact that the mouse entered the element is lost during the FRAMECHANGE. This must be fixed because there are many style changes that require a FRAMECHANGE. Thus cc'ing jst. 2) In this case, changing the background shouldn't actually require a FRAMECHANGE. The reason we get a FRAMECHANGE is because the rule for the table cell changes from not specifying a background-attachement to specifying "scroll". nsCSSParser::AppendValue generates its change hint by looking at the change in the rule alone, rather than by looking at the change in the computed style for the particular element. This could be, and probably should be, made smarter, but I'm not sure how best to do that. CC'ing dbaron.

Regarding (2). I've been thinking we might want to get rid of the hints that are in nsCSSPropList.h (which is the relevant hint that you're talking about). I'm not sure if any of the optimizations they make are useful anymore. (Were they ever?) The best way to do that is probably to eliminate one caller at a time. I just filed bug 158713 to examine doing this. roc, which testcase where you analyzing in your previous comment?

Attachment 85477 [details] is the testcase I was looking at. Doing reresolution and getting the change hint from there is exactly what we need here.

joki's the event state manager man. I always confuse him with jst!

*** Bug 151893 has been marked as a duplicate of this bug. ***

*** Bug 173535 has been marked as a duplicate of this bug. ***

Another example: Lefthand buttons on http://www.microsoft.com/Australia/

This is effecting top sites in Australia and Germany. Marking as nsbeta1+

bz's inline style fix should help with this kind of bug. Another thing that I'm thinking of doing that will help is to make it so when a style change demands a view, instead of reframing, we'll create a view for the existing frame and jam it directly into the view hierarchy (then reflow the existing frame to make sure the view is set up properly). This shouldn't be much work and will improve performance in certain cases. The frame-based ESM code still needs to be fixed up, though.

changing background property to backgroundColor is a trivial workabout for this bug.

Does this need to be reassigned??

*** Bug 146808 has been marked as a duplicate of this bug. ***

*** Bug 184445 has been marked as a duplicate of this bug. ***

*** Bug 184727 has been marked as a duplicate of this bug. ***

It looks to me like bug 103055 fixed this (in my debug build at least). Could you guys retest with tomorrow's build?

Oh yeah. John, You rock! This is fixed in build 2002-12-17-08-trunk

can you check TB15208182M ? I just crashed with build 2002121708 on Linux browing http://wfrv_new.webtest.netnet.net/ and hovering the menus.

Wow, that was a hard crash! Talkback has no stack trace for it: Incident ID 15208182 Stack Signature 0x0000000b f475f2f3 Email Address cahagn_o@epita.fr Product ID MozillaTrunk Build ID 2002121708 Trigger Time 2002-12-17 11:23:02 Platform LinuxIntel Operating System Linux 2.4.17-10mdk Module URL visited http://wfrv_new.webtest.netnet.net/ User Comments bug 130620, loading URL Trigger Reason SIGSEGV: Segmentation Fault: (signal 11) Source File Name Trigger Line No. Stack Trace 0x0000000b

0x0000000b is par for the course on linux. see bug 176886

http://wfrv_new.webtest.netnet.net/ crashes in windows xp also with build 2002121704

Update: looks like the crash is a regression due to the fix for bug 103055. Bug 185850 has been filed: "Crash on http://wfrv_new.webtest.netnet.net"

verifying