Garbage is displayed when root svg element has mix-blend-mode set

Created attachment 264043 [details]
test file which has svg root element with mix-blend-mode

If the mix-blend-mode css property has been set to something else than "normal" in the root svg element, then the page displays garbage (possibly unallocated memory?).

Steps to reproduce:

1. Open the attached mixblend.svg file in the browser
2. Resize the browser window to see garbage

I expect to see a yellow rectangle with a white page background, not garbage.

Tested Safari 9.0.1 and Webkit nightly (10601.2.7.2, r191553).

> (possibly unallocated memory?)

I meant uninitialized :)  Also, the svg document needs to be opened as a top level document.

[Radar WebKit Bug Importer]

<rdar://problem/23270918>

[Said Abou-Hallawa]

Created attachment 269719 [details]
Patch

[Darin Adler]

Comment on attachment 269719 [details]
Patch

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

> Source/WebCore/ChangeLog:15
> +        In SVGRenderingContext::prepareToRenderSVGContent(), the clip() is called
> +        before beginTransparencyLayer() which calls save(). We need to move this
> +        call after the call to beginTransparencyLayer() to ensure the clipping will
> +        be restored to its previous state when endTransparencyLayer() is called in
> +        the destructor of SVGRenderingContext.

This is surprising.

I thought that:

1) setting a clip before calling beginTransparencyLayer reduces the amount of memory that has to be allocated in order to create a transparency layer
2) endTransparencyLayer does not guarantee a restore

I was probably wrong about (2), but was I wrong about (1)? Can we just add another save/restore instead?

[Simon Fraser (smfr)]

Comment on attachment 269719 [details]
Patch

This seems like the wrong approach. I think what's missing is a save/restore around setting the clip.

[Said Abou-Hallawa]

Created attachment 269967 [details]
Patch

[Said Abou-Hallawa]

Created attachment 269968 [details]
Another test case

[Said Abou-Hallawa]

Yes I took a wrong approach in the previous patch.

I was trying that patch on WK1 with test cases which do not force compositing. These test cases did not produce the bug with or without the patch.

[Said Abou-Hallawa]

Created attachment 269978 [details]
One more test case

[WebKit Commit Bot]

Comment on attachment 269967 [details]
Patch

Clearing flags on attachment: 269967

Committed r195724: <http://trac.webkit.org/changeset/195724>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.