problem when is set dynamically by function invoked from setInterval




DOM: Events
14 years ago
13 years ago


(Reporter: Sylwester Zelazko, Unassigned)




Firefox Tracking Flags

(Not tracked)




(1 attachment, 1 obsolete attachment)



14 years ago
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

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.
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....
Whiteboard: DUPEME
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

14 years ago
dupe of bug 6316?

Comment 4

14 years ago
Created attachment 158412 [details]
Test case showing the interval is never created when opacity set to 1

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

Comment 5

14 years ago
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).

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.
Keywords: testcase

Comment 6

14 years ago
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

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


14 years ago
OS: Linux → All
Hardware: PC → All

Comment 8

14 years ago
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;

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
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

13 years ago
Created attachment 177185 [details]
similar testcase, :hover and onmouseout not firing

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

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


13 years ago
Attachment #158412 - Attachment is obsolete: true


13 years ago
Ever confirmed: true
This works for me in a trunk build from today. Some recent ESM changes may have
fixed it. Tarmo, can you check?

Comment 11

13 years ago
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
Last Resolved: 13 years ago
Resolution: --- → WORKSFORME
Whiteboard: DUPEME
You need to log in before you can comment on or make changes to this bug.