Closed
Bug 142004
Opened 23 years ago
Closed 23 years ago
opacity doesn't change onmouseover and onmouseout (framechange confuses events)
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Core
DOM: UI Events & Focus Handling
Tracking
()
RESOLVED
FIXED
People
(Reporter: tunaman, Assigned: joki)
References
()
Details
(Keywords: testcase)
Attachments
(2 files)
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:1.0.0+) Gecko/20020502
BuildID: 2002050203
When you move your mouse over the red div, the opacity should change, but it
doesn't. It works in Netscape 6.2.2 but not in this build (20020502).
Reproducible: Always
Steps to Reproduce:
1. go to URL
2. Hover over red <div>
3.
Actual Results: nuttin happens!!
Expected Results: <div> should become 50% less opaque.
Think something is broken in between 0.9.9 and 1.0 RC 1 have confirmed that it
works on 0.9.8, couldn't test on 0.9.9 If someone could confirm for 0.9.9
|
Reporter | |
Comment 1•23 years ago
|
||
Some of the other currently open moz-opacity bugs are:
bug 44401, bug 66022, bug 92723, bug 92781, bug 93820, bug 119070, bug 127435,
bug 136978
|
|
Reporter | |
Comment 3•23 years ago
|
||
yup, i did go trough the mentioned bugs, but this one is different (i guess they
will be related though)
This problem only occurs if you set the Opacity to 1 (doesn't happen if you set
it to anything else).
It seems to me that when you set Opacity to 1 from something other than 1, the
next mouseout event is ignored.
|
||
Comment 5•23 years ago
|
||
Confirming on Linux RC3.
I modified the testcase so it shows 4 DIVs. Two upper don't change (as
reported), in two lower the opacity is set to 1.01 and they work OK, although
for me they start at 2nd or third attempt (another bug?). The ones on the left
are set to 0.5 on mouseout, the right ones on mouseover.
|
|
||
Comment 6•23 years ago
|
||
adding testcase keyword in order to remove from BugAThon testcase needed list.
Changing OS to "all" (reproductible on Linux, RC3, i386)
Adding verifyme keyword. (somebody test it on other OS?)
Adding "and onmouseout" to Summary (this one seems related, doesn't it?)
CC: self.
|
||
Comment 8•23 years ago
|
||
Confirming. Looks like variations for #144832 . DUPE ?
|
|
Reporter | |
Comment 9•23 years ago
|
||
I think what Bartosz descripes is actually bug 144832 [quote]....and they work
OK, although for me they start at 2nd or third attempt (another bug?)[/quote]
But i guess they are both closely related, though seperate bugs. As his testcase
more or less works, mine doesn't work at all, but it did in Mozilla prior to 1 RC1.
Can we change the state of the bug to "New" ?
|
||
Comment 10•23 years ago
|
||
I see it also. Mac G3 OS X.
|
||
Comment 11•23 years ago
|
||
So the real problem here is that the opacity change causes the frame to be blown
away and reconstructed. This screws up the mouseover/out handling....
Assignee: jst → joki
Status: UNCONFIRMED → NEW
Component: DOM Mozilla Extensions → Event Handling
No longer depends on: 144832
Ever confirmed: true
QA Contact: lchiang → rakeshmishra
Summary: opacity doesn't change onmouseover and onmouseout → opacity doesn't change onmouseover and onmouseout (framechange confuses events)
|
||
Comment 12•23 years ago
|
||
The change of Opacity doesn't always cause the mouseout to be lost (Moz 1.1b) -
if it's changed as per fadein1() the image is reloaded on every change of style,
while with fadein2() the mouseouts are only lost once the opacity reaches 100%.
Very odd!
<html><head>
<title>MozOpacity bugs</title>
<SCRIPT LANGUAGE="JavaScript" style="text/javascript">
op1 = 0; op2 = 0;
timer1 = null; timer2 = null;
function fadeup1(){
clearTimeout(timer1);
if (op1<100) {
op1+=10;
document.home.setAttribute("style","-moz-opacity: "+ op1 + "%;");
timer1=setTimeout("fadeup1()", 300);
}
}
function fadedown1(){
clearTimeout(timer1);
if (op1>0) {
op1-=10;
document.home.setAttribute("style","-moz-opacity: "+ op1 + "%;" );
timer1=setTimeout("fadedown1()", 300);
}
}
function fadeup2(){
clearTimeout(timer2);
if (op2<1) {
op2+=0.1;
document.home2.style.MozOpacity= op2 ;
timer2=setTimeout("fadeup2()", 300);
}
}
function fadedown2(){
clearTimeout(timer2);
if (op2>0) {
op2-=0.1;
document.home2.style.MozOpacity= op2 ;
timer2=setTimeout("fadedown2()", 300);
}
}
</SCRIPT>
</head>
<body>
<TABLE border="2"><TR>
<TD ><A HREF="javascript:void(0)"
onMouseOver="fadeup1();"
onMouseOut="alert('mouse out 1');fadedown1()">
<img name="home" onload="window.status='loaded '+this.style.MozOpacity"
src="http://www.mozilla.org/images/mozilla-banner.gif"></A></TD>
</TR><TR>
<TD ><A HREF="javascript:void(0)"
onMouseOver="fadeup2();"
onMouseOut="alert('mouse out 2'); fadedown2()">
<img name="home2" onload="window.status='loaded2 '+this.style.MozOpacity"
src="http://www.mozilla.org/images/mozilla-banner.gif"></A></TD>
</TR></TABLE>
</CENTER>
</body>
</html>
|
|
||
Comment 13•23 years ago
|
||
*** Bug 165704 has been marked as a duplicate of this bug. ***
|
|
||
Comment 14•23 years ago
|
||
roc, this would be fixed if we made opacity change just viewchange, not
framechange, no? I can't find the bug on that....
That would fix this particular bug, but the real issue is that FRAMECHANGE
confuses the heck out of the event state manager. So this bug is really the same
as bug 130620, and it really is joki's :-).
|
||
Updated•23 years ago
|
QA Contact: rakeshmishra → trix
|
||
Comment 16•23 years ago
|
||
WFM (2002121708, Win 2000) now that bug 130620 is fixed.
Yes, it should be fixed now.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
|
||
Updated•6 years ago
|
Component: Event Handling → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•