Open Bug 360875 Opened 18 years ago Updated 3 years ago

Mouseout event triggered for parent when mouseover on autocomplete drop down

Categories

(Core :: DOM: Events, defect, P5)

Product:
Core
Component:
DOM: Events
Version:
1.8 Branch
Platform:
PowerPC
All
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: komi, Unassigned)

Details

Attachments

(1 file)

testcase from comment 0
321 bytes, text/html
Details 
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0

Seems like there are many bugs logged relating to events that are fired when interacting with the autocomplete drop down. This bug is of the same family-

An onmouseover event is set for a div tag that contains an input of type text. The onmouseover is continuously fired when the cursor is over the div tag and the input - this is correct. The onmouseover is NOT fired when the cursor is over the autocomplete dropdown box when it appears - this is not correct.

Reproducible: Always

Steps to Reproduce:
Given the following code:

<html>
<body>
<div style="width:200px; height:200px; padding:100px; margin:0 auto; background-color:red;" onmouseover="this.style.backgroundColor='green';" onmouseout="this.style.backgroundColor='red';">
<form><input id='remember_me' type="text"/></form>
</div>
</body>
</html>

1. Place the cursor over the red box and confirm that it turns green.
2. Type in a text string in the input box and press enter to add the string.
3. Type in the beginning of the text string from step 2 to display the autocomplete dropdown.
4. Place the cursor over the autocomplete dropdown and observe that the green box turns red - indicating that the onmouseover event is no longer being fired.
Actual Results:  
Onmouseover event is not fired when the cursor is over the div and over the autocomplete dropdown.

Expected Results:  
Onmouseover event should be fired if the cursor is over the div and its contents - which includes the autocomplete dropdown.
OS: Mac OS X 10.4 → All
Reporter, do you still see this problem with the latest Firefox 2? If not, can you please close this bug as WORKSFORME. Thanks!

If it doesn't, could you please attach the html in comment 0 to this bug as a testcase ('Add an attachment')

Also, testing with the latest trunk build would be useful
- http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
Whiteboard: CLOSEME 07/14
Version: unspecified → 2.0 Branch
Component: Form Manager → DOM: Events
Product: Firefox → Core
QA Contact: form.manager → events
Version: 2.0 Branch → 1.8 Branch
Over to DOM Events to see what they have to say.
Whiteboard: CLOSEME 07/14
  Keisuke Omi, testcase doesn't function as I would expect. I don't see any text after hitting enter in step 2. can you retest please?
Whiteboard: closeme 2009-09-15
Maybe I should've been more verbose? Does this help?

1 [user] open https://bug360875.bugzilla.mozilla.org/attachment.cgi?id=274622
2 [user] place the cursor over the red box
3 [system] update background color from red to green because the cursor is in the box
4 [user] type in a text string - eg: "aaa" - in the input box
5 [user] press enter to submit the form
6 [system] display https://bug360875.bugzilla.mozilla.org/attachment.cgi?
7 [system] add the string entered in step 4 to the list of autocomplete options for the input id
8 [user] click back button to return to https://bug360875.bugzilla.mozilla.org/attachment.cgi?id=274622
9 [user] place the cursor over the red box
10 [system] update background color from red to green because the cursor is in the box
11 [user] enter the first character of the string from step 4 - eg: "a"
12 [system] display dropdown with autocomplete options
13 [user] place cursor on top of one of the dropdown options - eg "aaa"
14 [system] update background color from green to red <- BUG

Expected results:
14 [system] don't do anything - background color should remain green - because the cursor is still in the box
Whiteboard: closeme 2009-09-15
3 years later, using Keisuke Omi's 14 step instructions I can easily replicate this issue.

Are there any updates on this at all?
Looks like an invalid bug to be.
Mouse is not over the input element when it is over autocomplete popup.
Olli - I don't think you understand the bug correctly. Have opened the attached testcase and walked through the steps to reproduce?
I do understand it correctly. Mouse moves over the autocomplete popup which is not part of the
document, so mouseout is dispatched to the document.
Though, one could argue that the autocomplete popup is part of the input element.
In that cause mouseout shouldn't be dispatched.
s/cause/case/
Cool. I was just making sure.

Not knowing the inner workings of app, my expectation is that the autocomplete popup is the child of the form element and should behave as such.
Got this complaint from Twitter today. I'd think Comment 10 is more logical from a user point of view.
This is nasty because in my case it looks like the user is leaving the page every time the mouse attempts an autocomplete.
Any news about the fix Is there any known workaround? 
Is it possible to reach the autocomplete box from within JS code?
I'm encountering the same problem with onmouseover and onmouseout events. In my case, a class is added to the body in the onmouseover, the class is removed in the onmouseout event. This change of classes makes the select dropdown disappear because onmouseout is fired when you hover the dropdown. There's no workaround using other events or CSS-only and I need to guarantee browser compatibility for a client.
(In reply to gidomanders from comment #15)
> I'm encountering the same problem with onmouseover and onmouseout events. In
> my case, a class is added to the body in the onmouseover, the class is
> removed in the onmouseout event. This change of classes makes the select
> dropdown disappear because onmouseout is fired when you hover the dropdown.
> There's no workaround using other events or CSS-only and I need to guarantee
> browser compatibility for a client.

I actually just kind of fixed a workaround for my case, using a mouseover and mouseout on "document" instead of the element, and in the function checking if the event target is the element. This way javascript has to work a lot harder, but it makes the user experience work a lot better...
I just wanted to add my 2 cents. I agree that comment 10 would be the logical behaviour from a UI/UX standpoint. Also, this appears to be how it is handled in Chrome.

Bulk-downgrade of unassigned, 4 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.

Severity: normal → S4
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: