WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
76478
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
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.
Top of Page
Format For Printing
XML
Clone This Bug