357651 - codes of onmouseover lost.

Status: VERIFIED FIXED

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

Description

[Yiming Lu]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7

Sorry for that this bug not on a common URL.

I dynamiclly generate a whole page in a Iframe, with document.write(). After the page in the iframe show correctly, I quickly move mouse on the page, to fire onmouseover of some TRs, while there are other scripts are running in other Iframes. The onmouseove will not be fired on some time. When I write the code of the onmouseover into another element's innerHTML, it show "undefined".

I tried write onmouseover codes for BODY, it is fine (fired) always, even the TR's onmouceover is stoped. This means, I think, the event bubbled to BODY throungh the TR.

Except the onmouseover, other events seems fine.

I tesed, this bug exist on Firefox 1.5.0.7 and new 2.0.x, but not on 1.5.0.6, both on Windows(XP/Vista RC1) and Linux. So I think you must changed something in 1.5.0.7 relateve onmouseover.

--------------------------------
I like Firefox, but I spent one more week to get around this bug :)

Reproducible: Sometimes

Steps to Reproduce:
Sorry, this not occurs on a common URL, so you can't reproduce it :(
Actual Results:  
document.getElementById('new_td').innerHTML = document.getElementById('bug_tr').onmouseover;
On most times, it show the correct codes of the event, but on some times, it show "undefined".

Expected Results:  
onmouseover works.

Comment 1

[Mats Palmgren (inactive)]

Please upload a small example that demonstrates the bug using the
"Create a New Attachment" on the bug report. Thanks.

Comment 2

[Yiming Lu]

Attachment: A example can be used to reproduce the bug.

How to reproduce this bug:

When the page is loading, move mouse quickly and repeatlly over/out the "Action" on the page top, so a "DropDown menu" will show, and continue to move the mouse on the "menu" will Yahoo's page is loading. After Yahoo's page loaded, you will find some of menu items will "stop work", as it's color not change to yellow while mouse over it.

When this bug not appears: if you move the mouse over the items after Yahoo's page totally loaded.

If you add more scripts to find the reason of the bug, you will find THE EVENT OF ONMOUSEOVER OF THE TR LOST, and on Error console of Firefox you will see "the  onmouseover not defined".

Note: this bug is not caused by Yahoo's page. Yahoo is just a example, you can replace to others website, the bug still exist.

Comment 3

[Mats Palmgren (inactive)]

Attachment: Somewhat reduced testcase

It looks to me like we're not calling onmouseover/onmouseout in some cases,
but we need to reduce the testcase even more to tell for sure...

Regression window on Firefox trunk Linux: 2006-04-10-04 -- 2006-04-11-07

Comment 4

[Martijn Wargers (dead)]

Attachment: Somewhat reduced testcase

The "Somewhat reduced testcase" didn't work anymore with current trunk builds, because of the fix for bug 47903. This is a fixed version.

Comment 5

[Martijn Wargers (dead)]

Attachment: Minimised testcase

This regressed on 1.8.1 branch between 2006-07-27 04 and 2006-07-28 05, so with those regression dates, I think this is a regression from bug 321299.

Comment 6

[Martijn Wargers (dead)]

This is also a problem in the 1.8.0.x branch.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Attachment: Somewhat more minimized, with more detailed instructions.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Attachment: Er, need the function

Comment 9

[Boris Zbarsky [:bzbarsky]]

OK, so I'm seeing the wrapper for the div get GCed, even though it got added to the preserved wrapper table...  I tried the obvious thing of making nsDocument::AppendReachableList append mRootContent, but this bug still happened.

What _does_ fix this bug is if I change the testcase to:

  var idoc2;
  function doe() {
  ...
    idoc2=window.frames[0].document;
  ...

Comment 10

[Boris Zbarsky [:bzbarsky]]

So this is weird....  I'd expect the document to be protected from GC via the window, no?

Comment 11

[Johnny Stenback (:jst)]

Attachment: Fix, don't remove our cached window.document property when reusing an inner window for the same document.

Comment 12

[Johnny Stenback (:jst)]

Attachment: diff -w of the above.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 247025 [details] [diff] [review]
diff -w of the above.

Looks good, but why was this needed?  I'd have thought that at least on trunk the nsGlobalWindow::AppendReachableList impl would have kept the document alive...

Comment 14

[Jay Patel [:jay]]

jst/bz:  How important is it to get this on the branches right now?  Patch looks simple enough, but without baking time on the trunk, want to make sure it's safe for 1.8.0.9 and 1.8.1.1.  Let us know and ask for approvals.  Thanks!

Comment 15

[Boris Zbarsky [:bzbarsky]]

I think we should get this in on branches, myself.

Comment 16

[Johnny Stenback (:jst)]

Fix landed on the trunk. I'm also curious as to why this is needed to keep the wrapper alive, but either way this is the right thing to do so I landed this on the trunk in hope it would help get testing along with the branches (and I too think we should take this for the branches).

Comment 17

[Daniel Veditz [:dveditz]]

Marking fixed per comment 16

Comment 18

[Jay Patel [:jay]]

Johnny:  I'm assuming the patch is also good for both 1.8 and 1.8.0 branches...if so, please ask for approvals so I can grant them.  Thanks!

Comment 19

[Jay Patel [:jay]]

Comment on attachment 247025 [details] [diff] [review]
diff -w of the above.

Approved for 1.8 and 1.8.0 branches, a=jay for drivers.  Thanks jst!

Comment 20

[Johnny Stenback (:jst)]

Fix landed on branches.

Comment 21

[Carsten Book [:Tomcat]]

Verified fixed for 1.8.0.9 on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.9) Gecko/20061206 Firefox/1.5.0.9 and for 1.8.1.1. on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.1) Gecko/20061208 Firefox/2.0.0.1 ID:2006120814. Also tested  Windows XP x64.