Bug 76478

Summary:

REGRESSION: iframes with composited contents are not transparent in WK1

Product:

WebKit

Reporter:

Simon Fraser (smfr) <simon.fraser>

Component:

Layout and Rendering

Assignee:

Adrienne Walker <enne>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

adele, enne, fpizlo, jamesr, simon.fraser, webkit-bug-importer, webkit.review.bot

Priority:

Keywords:

InRadar

Version:

528+ (Nightly build)

Hardware:

Unspecified

OS:

Unspecified

Attachments:

Description	Flags
Patch	none

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	Details Formatted Diff Diff
View All Add attachment proposed patch, testcase, etc.

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

<rdar://problem/10710494>

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

Created attachment 140636 [details] Patch

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.