RESOLVED FIXED 4334
REGRESSION: Flickering when css-hover should change opacity on floating elements
https://bugs.webkit.org/show_bug.cgi?id=4334
Summary REGRESSION: Flickering when css-hover should change opacity on floating elements
Jonas Munk
Reported 2005-08-08 06:20:46 PDT
When hovering over an element that has been assigned a css-float-value AND should change opacity it "flickers" instead. See the URL for a minimal testcase. The problem is found in Safari Version 2.0 (412.2). I remember that it worked in Safari 1.2 or so. I also remember seeing someone else found it as a regression on Hyatts old blog. Hep hey - my first bug :-)
Attachments
Same file as the URL (1.09 KB, text/html)
2005-12-01 14:05 PST, Jonas Munk
no flags
Update the noPaint flag as necessary (4.15 KB, patch)
2006-06-05 16:38 PDT, mitz
no flags
Patch, including change log and pixel test (36.53 KB, patch)
2006-06-06 07:52 PDT, mitz
hyatt: review-
Patch, including change log and pixel test (36.46 KB, patch)
2006-06-07 00:24 PDT, mitz
darin: review+
Patch that fixes the mezzoblue version of this bug (2.85 KB, patch)
2007-03-30 02:50 PDT, Dave Hyatt
mitz: review+
Test case to go with patch (1.25 KB, text/html)
2007-03-30 03:00 PDT, Dave Hyatt
no flags
Mark Rowe (bdash)
Comment 1 2005-08-15 03:36:38 PDT
Confirmed with both Safari 412.2 and ToT WebKit.
Jonas Munk
Comment 2 2005-12-01 14:05:27 PST
Created attachment 4897 [details] Same file as the URL Attached the test just to be sure it doesn't go away.
Jonas Munk
Comment 3 2005-12-01 14:08:44 PST
Can anyone tell me if this bug has any priority or maybe it is dependant on some other actvity?
Maciej Stachowiak
Comment 4 2006-01-12 14:44:53 PST
It's unassigned, so no one is actively working on it. Priority would go up if it affects a major site, is shown to be a regression, otherwise become higher profile than standard.
Jonas Munk
Comment 5 2006-01-18 00:42:11 PST
I understand. Actually I believe it is a regression (it worked a long time ago / when you first started supporting opacity) - but I'm unable to prove that :-) As of nightly 2006-01-17 the problem no longer occurs on the news-box on jonasmunk.dk ("Nyheder"). But it still occurs on www.in2isoft.dk (the links in the top-right corner)
Dave Hyatt
Comment 6 2006-01-18 00:44:07 PST
Yeah I'm sure this is a regression.
Jonas Munk
Comment 7 2006-01-18 00:55:52 PST
Just tried it in different versions of OmniWeb. It worked in OmniWeb 5.1 - should be AppleWebKit/125.4 according to http://www.omnigroup.com/applications/omniweb/developer/ Can be downloaded here: http://browsers.evolt.org/?omniweb/MacOSX/5.1 So I guess it's a regression
mitz
Comment 8 2006-01-18 09:11:32 PST
I think this is what's happening: when the float is first inserted into its containing block, because it's transparent it has a layer, and therefore the containing block sets noPaint to true. When it becomes opaque, it loses the layer but the containing block doesn't update the noPaint flag, so nobody paints the float. I suspect that in the opposite situation, the float is painted twice.
Joost de Valk (AlthA)
Comment 9 2006-01-22 04:41:05 PST
Upping to P1 because this is a regression.
Darin Adler
Comment 10 2006-01-22 15:55:56 PST
I thin Mitz's analysis is right. But I couldn't figure out the right way to get the noDraw bit updated properly when a child's layer changes in RenderBox::setStyle. Need to talk to Dave about this one.
Alice Liu
Comment 11 2006-01-26 17:41:45 PST
mitz
Comment 12 2006-06-05 16:38:57 PDT
Created attachment 8720 [details] Update the noPaint flag as necessary This is work in progress.
mitz
Comment 13 2006-06-06 07:52:15 PDT
Created attachment 8727 [details] Patch, including change log and pixel test
Darin Adler
Comment 14 2006-06-06 09:50:46 PDT
Comment on attachment 8727 [details] Patch, including change log and pixel test This patch probably needs to be reviewed by Hyatt. I don't understand the issues well enough to review its behavior. + RenderObject* o = parent(); + while (o && (!lastBlock || !o->layer())) { + if (o->isRenderBlock()) + lastBlock = o; + o = o->parent(); + } I think this reads better as a for loop. I'd also make lastBlock be a RenderBlock* to put the cast to RenderBlock closer to the isRenderBlock call. for (RenderObject* o = parent(); o; o = o->parent()) { if (lastBlock && o->layer()) break; if (o->isRenderBlock()) lastBlock = static_cast<RenderBlock*>(o); } For me, it's easier to see what the loop is doing in this form. And since this code appears twice, I think it should be factored out into a helper function. It probably doesn't need to be a member function.
Dave Hyatt
Comment 15 2006-06-06 12:23:17 PDT
Comment on attachment 8727 [details] Patch, including change log and pixel test r=me
Dave Hyatt
Comment 16 2006-06-06 12:33:34 PDT
Comment on attachment 8727 [details] Patch, including change log and pixel test Minusing so you can address Darin's comments.
mitz
Comment 17 2006-06-07 00:24:24 PDT
Created attachment 8745 [details] Patch, including change log and pixel test Addressed Darin's comments.
Darin Adler
Comment 18 2006-06-07 08:36:54 PDT
Comment on attachment 8745 [details] Patch, including change log and pixel test r=hyatt :-)
Darin Adler
Comment 19 2006-06-07 09:22:27 PDT
Committed revision 14759.
Dave Hyatt
Comment 20 2007-03-30 02:48:34 PDT
Reopening.
Dave Hyatt
Comment 21 2007-03-30 02:50:31 PDT
Created attachment 13886 [details] Patch that fixes the mezzoblue version of this bug
Dave Hyatt
Comment 22 2007-03-30 02:51:14 PDT
Changed the URL field to the test case that fails.
Dave Hyatt
Comment 23 2007-03-30 03:00:39 PDT
Created attachment 13887 [details] Test case to go with patch
mitz
Comment 24 2007-03-30 03:00:59 PDT
Comment on attachment 13886 [details] Patch that fixes the mezzoblue version of this bug I'm told there's a test to go with this patch, so r=me!
Dave Hyatt
Comment 25 2007-03-30 03:07:58 PDT
Fixed in r20609.
Note You need to log in before you can comment on or make changes to this bug.