267842 - double DOM mouseOut/mouseOver event generation for elements with position: fixed (javascript)

Status: RESOLVED WORKSFORME

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

Description

[Navid Zamani]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10.1

On the example page you can see that javascript/dom event-handlers recieve too
many mouseover/mouseout events. the secquence is:
position: fixed --> (mouse goes over), over, out, (mouse moves a pixel more
inside), over, (mouse goes out), out
correct: position: absolute --> (mouse goes over), over, (mouse goes out), out

it's really strange because i seem to recieve an over/out just on the border,
and a second over on the inside... is the border inside AND outside and for that
reason it generates both events? ;

Reproducible: Always
Steps to Reproduce:
1. open my example page
2. move the mouse just over the border of the red block marked "fixed"
3. move it inside the block
4. check the blue event-log box
5. do the same for the block called "absolute" to compare the behavoiur

Actual Results:  
i got the following log output:

fixed: over
fixed: out
fixed: over
fixed: out
absolute: over
absolute: out

Expected Results:  
the log output should be:

fixed: over
fixed: out
absolute: over
absolute: out

This "works" for functions added with addEventListener() too.

I hope it's not related to any extension...

Comment 1

[Nickolay_Ponomarev]

I can see this with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5)
Gecko/20041022, moving to Browser:Event Handling

I think it is related/same as bug 83111, but I can't say for sure now.

Comment 2

[Nickolay_Ponomarev]

Attachment: testcase

attached the provided testcase

Comment 3

[Navid Zamani]

Did you want the attachment to be modifyed by having a pre-filled log?

Comment 4

[Navid Zamani]

Good news! I found some additional infos and have prepared a second test case
under the old URL (http://cyberworldz.org/pub/fixed_event_bug.html).

Now you can see the event.target and event.relatedTarget's tag-type and id in
the log.

By trying the reproduction steps you will notice that the the fixed element's
wrongly created redundant events have the relatedTarget NULL! (if the property
is NULL, this is shown instead of the "id" sub-property)

I hope this helps to track down the bug easily. :)
At least it provides the workaround to check for the existance of the
relatedTarget to filter out the erroneous events.

(If no none has time to fix this right now, I could look at the code myself. But
because i never looked inside this code before someone would have to show me the
file(s) and code-positions that could be related to that thing. And i only could
find but not rewrite the code, because i'm only able to read c-code right now.
But at least someone other could fix it in 5-15 minutes... :)

Comment 5

[Boris Zbarsky [:bzbarsky]]

This is almost certainly a duplicate, having to do with us using widgets to
dispatch events...  Please find the original and mark this duplicate.

Comment 6

[Nickolay_Ponomarev]

Hope I found the right bug.

Comment 7

[Nickolay_Ponomarev]

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

Comment 8

[José Jeria]

WFM: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050612
Firefox/1.0+

CAn you please reteset with a nightly build?

Comment 9

[Martijn Wargers (dead)]

Also WFM with 2005-07-02 trunk build.

Comment 10

[José Jeria]

Marking WFM then, please reopen if you can reproduce with a nighty trunk build

Comment 11

[Navid Zamani]

sorry, you really can't expect me to install a nightly build every morning, that
possibly does not even start on some days. i have to actually build sites with
it and rely on consistent behaviour if i don't want my clients to see something
sompletely different... so i have to wait for the next "official" version... any
idea when it will come out? ;P

Comment 12

[Nickolay_Ponomarev]

We don't expect you to use nightly builds. The comments above are indicating
that the bug is fixed in nightlies, and there's no point in keeping this bug NEW
in bugzilla.

The next version of Firefox will be out "when it's ready", I'm afraid. My
optimistic estimate would be sometime in October.

Comment 13

[Navid Zamani]

good. i'm okay with this. bug closed. ;)