237875 - problem when object.style.MozOpacity is set dynamically by function invoked from setInterval

Status: RESOLVED WORKSFORME

(Core :: DOM: Events, defect)

Description

[Sylwester Zelazko]

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

Check URL for example, there is JS which fade in object by changing MozOpacity
CSS style from 0.2 to 1. When object reach MozOpacity = 1 mozilla lost events
for this object, in this case mouseout event is not invoked. 

Reproducible: Always
Steps to Reproduce:
1.use javascript as in example URL, then point cursor to image with gradual 
fadein effect for enough time to reach no opacity (MozOpacity set to 1)
2.Move cursor out, there is onmouseout event which is not invoked after cursor out
3.

Actual Results:  
Function for event onmouseout is not invoked.

Expected Results:  
Function for event onmouseout should be invoked.

I'm able to reproduce this bug on Windows version too.

Comment 1

[Boris Zbarsky [:bzbarsky]]

The problem is that we're reframing when we hit opacity = 1, and I assume that
the ESM gets confused about what frame is currently hovered....

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

One of my near-term work items (which shouldn't be hard) is to allow
CreateViewForFrame to be done anytime, even if the frame has children with
views. (We'll reparent the views appropriately). That will get rid of a whole
lot of problems including this one.

However, the ESM really needs to be able to handle reframing.

Comment 3

[louis bennett]

dupe of bug 6316?

Comment 4

[Marty Vance]

Attachment: Test case showing the interval is never created when opacity set to 1

This document shows that the bug also applies to element.style.opacity, and
that interval creation does not happen only if code running in the previous
interval sets opacity to 1.

Comment 5

[Gérard Talbot]

Marty, your testcase looks very interesting. Some 2 years ago, I had a problem
with setTimeout ( for -moz-opacity, -khtml-opacity, IE filters) and manage to
work around the problem I faced. String conversion (style.opacity; say "0.1") to
float (0.1) is intentionally executed in the function and that solved my problem
(also rounding up float representation).

http://www10.brinkster.com/doctorunclear/HTMLJavascriptCSS/DynamicOpacity.html

I see improvements (and optimization) in your code and possibly a way to
workaround the problem which worked for me and still works for me with
style.opacity. I'm still not sure (I could be wrong) that there is a real
Mozilla bug here and at bug 6316.

Comment 6

[Gérard Talbot]

pct = Math.round((currFade / steps) * 100) / 100; // pct is a float here
document.getElementById('fader').style.opacity = pct; // function instruction
will "type conversion" (type coercition) assume pct from float to string.

This is where I would start investigation. Your testcase proves that internally
"1" != 1. In your testcase, when opacity value is 1, Positive value is false:
this is from where I would start investigating your code.
Also, 1.00000...1 != 1.

Comment 7

[Gérard Talbot]

<rant>Your testcase could be furthermore reduced; fadePos does not seem to me to
be really needed.</rant>

Comment 8

[Marty Vance]

I'll try to address the comments on my test case so far:

#5: My test case doesn't retreive opacity, it only sets it, so converting it is
moot.  Your code is much mroe verbose than mine... I use setInterval() instead
so I can "fire and forget", as it were, although we have achieved the exact same
effect (this bug notwithstanding).

#6: Originally, I was setting opacity using

pct = currFade / steps;
pct.toPrecision(2);

Apparently Safari 1.2+ supports opacity, but doesn't support toPrecision(), so I
changed the code and this test case works perfectly in safari.  This code also
executes as intended in IE6 (excepting opacity, of course).

#7:  It's not needed for the testcase, but it is needed to determine the
direction of the fade due to how this code is structured.


The actual bug can be observed by following this procedure:
1. Load page.
2. Mouse over image.  Fade begins, Interval ID is incremented by 1.
2b.  Optionally, mouse out before the fade completes.  Fade reverses, Interval
ID is again incremented by 1.
3.  Fade completes, setting opacity to 1.0.
4. Mouse out.  No fading occurs, the border color (meant as further visual
feedback on what is happening) doesn't change, and the Interval ID is not
incremented.
5.  Mouse over again.  Border color changes to red momentarily (showing that the
mouseover event handler was called), but Interval ID is not incremented,
suggesting that the interval object is not created.
6. Mouse out again.  Fading occurs as expected, including border color change,
but Interval ID is incremented by 2.

Following these steps, the incorrect behavior is always reproducable.

Comment 9

[Tarmo Järvalt]

Attachment: similar testcase, :hover and onmouseout not firing

Perhaps similar testcase, onmouseout doesn't fire on hover with different
opacity.

Fires: rv:1.7.4 Gecko/20041010
Doesn't fire: rv:1.8b Gecko/20050218

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This works for me in a trunk build from today. Some recent ESM changes may have
fixed it. Tarmo, can you check?

Comment 11

[Gérard Talbot]

Both testcases and URL work accordingly, as expected.
Seamonkey 1.5a rv:1.9a1 build 2005111009 and Firefox 1.5 rv:1.8 build 20051110 under XP Pro SP2 here.

Resolving as WORKSFORME