265051 - onmouseout event does not fire after setting element style.position to absolute

Status: RESOLVED WORKSFORME

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

Description

[Daniel Kabs, reporting bugs since 2002]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113

Hi there,

I'm writing a page that contains thumbnail images. Whenever the user hoovers the
mouse over an image, it should be replaced with the full image displayed in
original size. The thumbnail should be displayed again as soon as the user
leaves the image area.

The testcase will be included soon!

Expecting reevaluation, I'm nevertheless marking this bug as "major" because a
lot of web pages with dynamic content depend on this feature. This problem seems
to get too little attention as the number of other bugs with same problems show:
bug #236080
bug #220902
bug #264646
bug #230152
or even bug #247401


Reproducible: Always
Steps to Reproduce:
Reproducibility is "Every time" only if you don't move the mouse too hectically. :-)

Comment 1

[Daniel Kabs, reporting bugs since 2002]

Attachment: Testcase

This the promised testcase.

Move the mouse over the left ant and wait. The image will grow to the original
size. Moving the mouse out, will *not* shrink the image again. It does work on
the  right ant, though. I don't know why!

Tested with
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913

Comment 2

[Gérard Talbot]

Can you create a *_reduced_* testcase?
Why do you need to use setTimeout?
Why do you need to embed images in nested tables?
Why do you need to absolutely positioned images which are embedded in nested tables?

> a lot of web pages with dynamic content depend on this feature. This problem 
> seems to get too little attention as the number of other bugs with same problems

A lot of web pages with dynamic content increase image dimensions with an hover
of the mouse without a problem in Mozilla. There are other ways to do what it
seems to me that you want to do.
 
Here, regarding your page, you first need to create a reduced testcase with
valid code (zoom is not a valid attribute) that will show the problem, just show
the problem.

What is a Simplified Test Case, and How Do I Make One?
http://www.mozilla.org/newlayout/bugathon.html#testcase

Comment 3

[Daniel Kabs, reporting bugs since 2002]

Daniel,

I'll try to create a simplified testcase. Can you see the problem, though?

Regarding your questions:
- I need the setTimeout to make this scheme user friendly in case you have a
large image gallery. The delay prevents the images from popping up just by
moving over them (e.g. while the user moves the mouse to the image he wants to
zoom) or just moving the mouse over the page.
- Tables: The tables arrange the images on the page. Not all images thumbnails
have the same size or orientation. I don't see any problem here.
- absolute Position: The popup image has to be displayed centered with respect
to it's thumbnail position. That looks very nice. In the testcase the position
calculation has been omitted, though.

Regarding your complaint about the "zoom" attribute: It's been added so the
Javascript code can "find" the image elements that should be made "zoomable".
(Mind you, the page is already simplified. It was created automatically
containing a number of pictures, some with the zoom attribute. The the pictures
can vary, the Javascript code stays the same and is just added to the page).
Though this invalidates the HTML according to W3C specs, I don't think this is a
problem here.

Regarding your point "other ways to do that": I'd be very happy to hear about
them, don't hesitate to email me. :-) But I think this is the only possible
implementation because this way it's also possible to change the image src and
to add the delay!

Comment 4

[Gérard Talbot]

Daniel, I sent you a long email trying to give you useful responses, tools and
an understanding explaining to you how to best file bugreports at bugzilla.
Remember that we're all volunteers here: your problem and other bugs have
nothing to do with bugs not receiving attention. Quite on the contrary.

As far as I can see, the problem with your testcase is related to timeout
issues; the problem with your testcase has nothing to do with mouseout event
firing. Whatever the issue is, you can use alternate methods.

Comment 5

[Daniel Kabs, reporting bugs since 2002]

Attachment: rewritten testcase

According to request from "Daniel Ulrich", I rewrote the testcase:
- removed nested tables (actually there are no tables any more)
- removed change of image size
- used correct and validated markup (HTML 4.01 Transitional)

Comment 6

[Daniel Kabs, reporting bugs since 2002]

Daniel Ulrich,

thanks for your email and the hints. I changed the Summary accordingly.

The rewritten testcase relies on changing style.position to "absolute" after a
certain amount of time (-> setTimeout()). As far as my experiments show,
omitting one of these two things hides the bug.

Comment 7

[Daniel Kabs, reporting bugs since 2002]

Attachment: testcase V3

rewrote the testcase again:
- stripped fancy javascript features (objective code, closures)
- strict and validated HTML 4.01
- improved description of how to reproduce the bug.

Comment 8

[Daniel Kabs, reporting bugs since 2002]

Attachment: simplified testcase according to bugathon

Testcase with fixed delay of  one second. Set breakpoints on event handler
functions and then move over and out of the image. For detailed instructions
see "testcase V3"

Comment 9

[Daniel Kabs, reporting bugs since 2002]

Changed Summary.

Looking at the "Debug Log" in "testcase V3", I conclude:
Switching the element style.position to absolute (when the mouse is on the
element) makes Mozilla forget to trigger onmouseout (when the mouse leaves the
element).

But if you are moving the mouse around on the element *while* the style.position
is changed to absolute, the onmouseover event is triggered (again) and
accordingly onmouseout, too.

The "delay" in the testcase just defines the time, when the mouse movement has
to occur for onmouseover to trigger (again).

I'd like to know, how mozilla detects onmouseout/onmousemove events. Does it
store the borders or the areas of the corresponding elements? Does it check for
"mouse crosses a border" or "mouse is on area" after the mouse has been moved?

Comment 10

[Martin Creutziger [:MMx]]

I can reproduce testcase V3 and simplified testcase on MacOS X using Firefox
1.0. I will test with a recent trunk build shortly.

Comment 11

[Daniel Kabs, reporting bugs since 2002]

Hey everybody, 

if you read the comments and wonder if I am talking to myself, you are mistaken:
The "Daniel" I am talking to is (was?) Daniel Ulrich (aka Dr. Unclear), who
changed his bugzilla name to "Gérard Talbot".

Comment 12

[Daniel Kabs, reporting bugs since 2002]

Just tried Mozilla 1.7.7 (on Linux) and Firefox 1.0.4 (on Windows) but the
behaviour did not change, the bug is still in there. :-(

I wrote a reduced testcase, added detailed description on how to reproduce the
bug and tried to identify the problem as close as I can get from the user's
point of view. What else can I do to help to get this bug resolved?

Comment 13

[Daniel Kabs, reporting bugs since 2002]

Downloaded the nightly build firefox-1.6a1.en-US.linux-i686.tar.gz containing:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20050829 Firefox/1.6a1

and checked the testcase. 

Ooops, the bug has gone!

Wow great, marking as FIXED.

Comment 14

[Jason Bassford]

No specific bug / patch referenced as the fix.

-> WORKSFORME