RESOLVED FIXED76478
REGRESSION: iframes with composited contents are not transparent in WK1
https://bugs.webkit.org/show_bug.cgi?id=76478
Summary REGRESSION: iframes with composited contents are not transparent in WK1
Simon Fraser (smfr)
Reported 2012-01-17 14:19:57 PST
The pixel result of compositing/iframes/resources/repaint-after-losing-scrollbars-iframe.html from DRT shows that the iframes are showing up as opaque white. This reproduces in a WK1 window in Safari.
Attachments
Patch (1.59 KB, patch)
2012-05-07 17:42 PDT, Adrienne Walker
no flags
Simon Fraser (smfr)
Comment 1 2012-01-17 14:35:22 PST
I think http://trac.webkit.org/changeset/92874 may have broken this. FrameView::useSlowRepaints() returns 'false' for iframes with composited content, but Widget::paint() (in WidgetMac) relies on [[scrollView contentView] copiesOnScroll] to decide when to turn off background drawing.
Radar WebKit Bug Importer
Comment 2 2012-01-17 14:39:05 PST
Simon Fraser (smfr)
Comment 3 2012-01-17 14:41:21 PST
WidgetMac really needs to get at FrameView's m_contentIsOpaque bit, but that would be a layering violation.
Filip Pizlo
Comment 4 2012-05-02 18:36:06 PDT
The relevant test appears to pass as of r115915
Simon Fraser (smfr)
Comment 5 2012-05-02 18:37:47 PDT
compositing/iframes/resources/repaint-after-losing-scrollbars-iframe.html is the iframe source, not the actual test. I probably meant compositing/iframes/repaint-after-losing-scrollbars.html.
Filip Pizlo
Comment 6 2012-05-02 18:38:19 PDT
(In reply to comment #5) > compositing/iframes/resources/repaint-after-losing-scrollbars-iframe.html is the iframe source, not the actual test. I probably meant compositing/iframes/repaint-after-losing-scrollbars.html. I figured that's what you meant, and that is indeed what I'm referring to.
Simon Fraser (smfr)
Comment 7 2012-05-02 18:38:46 PDT
This still fails. enne, can you look at this?
Adrienne Walker
Comment 8 2012-05-07 11:14:00 PDT
(In reply to comment #7) > This still fails. enne, can you look at this? Sure, I can take a look.
Adrienne Walker
Comment 9 2012-05-07 17:42:04 PDT
Adrienne Walker
Comment 10 2012-05-07 17:43:27 PDT
(In reply to comment #9) > Created an attachment (id=140636) [details] > Patch I am not happy with this, but am unsure about how else to handle this. I don't think it's correct to assume that !ScrollView::canBlitOnScroll() implies !FrameView::m_contentIsOpaque. It's also very strange to me that drawsBackground is true for something that shouldn't draw a background. That paint function is a pile of assumptions.
Adrienne Walker
Comment 11 2012-05-21 15:40:26 PDT
smfr: ping
Adrienne Walker
Comment 12 2012-05-29 14:31:24 PDT
(In reply to comment #11) > smfr: ping smfr: re-ping? You asked me to fix this three weeks ago, so I uploaded a patch. Was this something you wanted landed? Otherwise, maybe this issue should just be WONTFIXed.
Simon Fraser (smfr)
Comment 13 2012-05-29 14:47:20 PDT
Comment on attachment 140636 [details] Patch Sorry for the delay.
WebKit Review Bot
Comment 14 2012-05-29 15:25:03 PDT
Comment on attachment 140636 [details] Patch Clearing flags on attachment: 140636 Committed r118840: <http://trac.webkit.org/changeset/118840>
WebKit Review Bot
Comment 15 2012-05-29 15:25:08 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.