Closed Bug 321098 Opened 19 years ago Closed 18 years ago

onmouseover alert() causing multiple stacked alert dialogs

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

1.8 Branch
x86
All
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: cbarney, Assigned: emaijala+moz)

References

()

Details

(Keywords: regression, testcase)

Attachments

(1 file)

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

If a form button with an onMouseover alert() function is positioned near the center of the page (horizontally and vertically), when the alert pop-up appears, it partially overlaps the form button. This overlapping causes the onMouseOver event to continuously fire, creating multiple stacked alert windows. Because they are stacked, the user only sees a single alert window that doesn't close no matter how many times he clicks the 'close' button.

Reproducible: Always

Steps to Reproduce:
1. Go to http://www.dawginc.com/docs/mozilla_bug.php
2. Follow instructions
Actual Results:  
Depending upon where the form button is positioned using the vertical scrollbar, I can make the problem appear or not appear.

Expected Results:  
A single alert window should appear, with focus, requiring the user to close to proceed with any new action on the page.
Indeed, something is going wrong with that testcase.
Assignee: nobody → events
Status: UNCONFIRMED → NEW
Component: General → Event Handling
Ever confirmed: true
Keywords: testcase
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → 1.8 Branch
Summary: Runaway Javascript loop causing multiple stacked alert() windows → onmouseover alert() causing multiple stacked alert dialogs
Works in 1.0.7, I suspect bug 297561.
Keywords: regression
Attached patch Win32 patch v1Splinter Review
In the continuation of Win32 mouse handling fixes, this patch makes the behavior match that of Linux, I believe. I suspect the order of mouse messages there is EXIT -> ENTER -> MOVE instead of what we had on Windows (MOVE -> EXIT -> ENTER), but haven't got a Linux build yet to verify (build underway). Anyway, having messages in this order makes sense. Otherwise we're processing move in a widget that hasn't been entered yet. 

This doesn't fix the problem completely however. Both Linux and Win32 show two dialogs, but it's not in my domain of knowledge to fix that.
Attachment #206727 - Flags: superreview?(roc)
Attachment #206727 - Flags: review?(roc)
Oh, and the patch is for trunk. 
OS: Windows XP → All
I verified that GTK has it as I suspected (EXIT -> ENTER -> MOVE).
Attachment #206727 - Flags: superreview?(roc)
Attachment #206727 - Flags: superreview+
Attachment #206727 - Flags: review?(roc)
Attachment #206727 - Flags: review+
Depends on: 342589
Ere, are you going to land this?
Oops, I've somehow lost this one. Anyway, the patch was checked in to trunk but branch needs its own version. Need to test because there are some differences.
Assignee: events → emaijala
I don't think it's feasible to try to get this into branch anymore. Anyone disagree?
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: