Bug 76478 - REGRESSION: iframes with composited contents are not transparent in WK1
Summary: REGRESSION: iframes with composited contents are not transparent in WK1
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Adrienne Walker
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2012-01-17 14:19 PST by Simon Fraser (smfr)
Modified: 2012-05-29 15:25 PDT (History)
7 users (show)

See Also:


Attachments
Patch (1.59 KB, patch)
2012-05-07 17:42 PDT, Adrienne Walker
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Fraser (smfr) 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.
Comment 1 Simon Fraser (smfr) 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.
Comment 2 Radar WebKit Bug Importer 2012-01-17 14:39:05 PST
<rdar://problem/10710494>
Comment 3 Simon Fraser (smfr) 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.
Comment 4 Filip Pizlo 2012-05-02 18:36:06 PDT
The relevant test appears to pass as of r115915
Comment 5 Simon Fraser (smfr) 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.
Comment 6 Filip Pizlo 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.
Comment 7 Simon Fraser (smfr) 2012-05-02 18:38:46 PDT
This still fails. enne, can you look at this?
Comment 8 Adrienne Walker 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.
Comment 9 Adrienne Walker 2012-05-07 17:42:04 PDT
Created attachment 140636 [details]
Patch
Comment 10 Adrienne Walker 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.
Comment 11 Adrienne Walker 2012-05-21 15:40:26 PDT
smfr: ping
Comment 12 Adrienne Walker 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.
Comment 13 Simon Fraser (smfr) 2012-05-29 14:47:20 PDT
Comment on attachment 140636 [details]
Patch

Sorry for the delay.
Comment 14 WebKit Review Bot 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>
Comment 15 WebKit Review Bot 2012-05-29 15:25:08 PDT
All reviewed patches have been landed.  Closing bug.