836 bytes, text/html
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....
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.
dupe of bug 6316?
14 years ago
Depends on: 6316
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 element.style.opacity, and that interval creation does not happen only if code running in the previous interval sets opacity to 1.
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.
<rant>Your testcase could be furthermore reduced; fadePos does not seem to me to be really needed.</rant>
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.
Created attachment 177185 [details] 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
This works for me in a trunk build from today. Some recent ESM changes may have fixed it. Tarmo, can you check?
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
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.