Bug 76329

Summary: Unmatched transparency layer begin/end on a filtered element with an opacity ancestor
Product: WebKit Reporter: Simon Fraser (smfr) <simon.fraser>
Component: Layout and RenderingAssignee: Simon Fraser (smfr) <simon.fraser>
Status: RESOLVED FIXED    
Severity: Normal CC: achicu, simon.fraser, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Testcase
none
Patch mitz: review+

Description Simon Fraser (smfr) 2012-01-13 19:10:47 PST
Created attachment 122531 [details]
Testcase

The attached test case hits ASSERTION FAILED: m_transparencyCount > 0 when painting, if the context has paintingDisabled() (e.g. when doing a Find in Safari).
Comment 1 Simon Fraser (smfr) 2012-01-13 19:15:35 PST
The issue is that RenderLayer::beginTransparencyLayers() bails if context->paintingDisabled() is true, so never starting the transparency layer. However, when rendering the child, filterPainter hands back a context with painting enabled. We then hit beginTransparencyLayers() in the if (localPaintFlags & PaintLayerPaintingCompositingForegroundPhase) clause, since haveTransparency was passed in from the ancestor.

We should just not apply filters if the context has painting disabled.
Comment 2 Simon Fraser (smfr) 2012-01-13 19:33:22 PST
Created attachment 122533 [details]
Patch
Comment 3 Radar WebKit Bug Importer 2012-01-13 19:34:38 PST
<rdar://problem/10695409>
Comment 4 mitz 2012-01-13 19:58:49 PST
Comment on attachment 122533 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=122533&action=review

> Source/WebCore/ChangeLog:14
> +        Manual test:
> +            ManualTests/filters/opacity-above-filter.html

Could this be a TestWebKitAPI test instead?
Comment 5 Simon Fraser (smfr) 2012-01-14 07:52:16 PST
http://trac.webkit.org/changeset/105019
Comment 6 Alexandru Chiculita 2012-01-16 00:29:52 PST
(In reply to comment #5)
> http://trac.webkit.org/changeset/105019

Thanks!