Closed Bug 357651 Opened 18 years ago Closed 18 years ago

codes of onmouseover lost.

Categories

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

x86
Linux
defect
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: lu_yi_ming, Assigned: jst)

References

Details

(4 keywords)

Attachments

(6 files, 2 obsolete files)

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.
Please upload a small example that demonstrates the bug using the "Create a New Attachment" on the bug report. Thanks.
Keywords: regression
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.
Attachment #243740 - Attachment mime type: text/plain → text/html
Attached file Somewhat reduced testcase (obsolete) —
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
The "Somewhat reduced testcase" didn't work anymore with current trunk builds, because of the fix for bug 47903. This is a fixed version.
Attachment #245005 - Attachment is obsolete: true
Attached file 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.
This is also a problem in the 1.8.0.x branch.
Assignee: nobody → general
Status: UNCONFIRMED → NEW
Component: General → DOM
Ever confirmed: true
Keywords: testcase
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → Trunk
Flags: blocking1.9?
Attached file Er, need the function
Attachment #246956 - Attachment is obsolete: true
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; ...
So this is weird.... I'd expect the document to be protected from GC via the window, no?
Flags: blocking1.8.1.1?
Flags: blocking1.8.0.9?
Blocks: 321299
Attachment #247025 - Flags: superreview?(bzbarsky)
Attachment #247025 - Flags: review?(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...
Attachment #247025 - Flags: superreview?(bzbarsky)
Attachment #247025 - Flags: superreview+
Attachment #247025 - Flags: review?(bzbarsky)
Attachment #247025 - Flags: review+
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!
Assignee: general → jst
I think we should get this in on branches, myself.
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).
Marking fixed per comment 16
Status: NEW → RESOLVED
Closed: 18 years ago
Flags: blocking1.8.1.1?
Flags: blocking1.8.1.1+
Flags: blocking1.8.0.9?
Flags: blocking1.8.0.9+
Resolution: --- → FIXED
Whiteboard: need branch patch/approval request
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!
Attachment #247025 - Flags: approval1.8.1.1?
Attachment #247025 - Flags: approval1.8.0.9?
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!
Attachment #247025 - Flags: approval1.8.1.1?
Attachment #247025 - Flags: approval1.8.1.1+
Attachment #247025 - Flags: approval1.8.0.9?
Attachment #247025 - Flags: approval1.8.0.9+
Fix landed on branches.
Whiteboard: need branch patch/approval request
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.
Status: RESOLVED → VERIFIED
Flags: blocking1.9?
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: