New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 738675 link

Starred by 2 users
Status: Available
Owner: ----
Cc:
█ brajkumar@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

Canvas with a WebGL context does not obey parent element's backface-visibility: hidden

Reported by baseten....@gmail.com, Jul 1 2017 
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36

Steps to reproduce the problem:
1. Put a canvas with a WebGL context inside a container element
2. Set backface-visibility: hidden and transform: rotateY(180deg) on the parent element

What is the expected behavior?
The canvas should no longer be visible

What went wrong?
The canvas is visible.

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 59.0.3071.115  Channel: stable
OS Version: OS X 10.11.6
Flash Version: 

In the test case you can see backface-visibility: hidden will work correctly if the canvas itself is rotated, but not the parent. Neither setting transform-style: preserve-3d or backface-visibility: hidden directly on the canvas element itself will work round the issue and in fact setting backface-visibility: hidden on the canvas element will also cause this bug to occur on a canvas with a 2d context.

Appears to be related to this fixed bug: https://bugs.chromium.org/p/chromium/issues/detail?id=99812
test.html
4.9 KB View Download

Comment 1 by sandeepkumars@chromium.org, Jul 5 2017

Labels: M-61 OS-Linux OS-Windows
Status: Untriaged (was: Unconfirmed)
Able to reproduce the issue using latest stable #59.0.3071.115 on Win 10, Mac 10.12.5 and Linux Ubuntu 14.04.

Observing same behavior since M45. Hence considering this issue as a Non-Regression issue and untriaging to get more inputs from Dev.

Issue is seen in latest M61 as well.

Thanks!!

Comment 2 by junov@chromium.org, Jul 17 2017

Components: -Blink>Canvas Blink>Compositing
The problem also happens with 2D canvases when the size of the canvas is greater than 256 by 256, which triggers the GPU rendering code path.  Both WebGL and and GPU-acelerated 2D put the canvas contents into a separate compositing layer. What seems to be happening is that the child content layer is not inheriting the backface visibility from the parent layer.

In the debugger, I was able to verify that we are indeed calling SetUseParentBackfaceVisibility(true); on the GraphicsLayer for the canvas content, but it does not look like this setting is being honored.

#0  blink::GraphicsLayer::SetupContentsLayer (this=0x3eb3188cda10, 
    contents_layer=0x846e1640c0)
    at ../../third_party/WebKit/Source/platform/graphics/GraphicsLayer.cpp:431
#1  0x00007f02f04ff4fd in blink::GraphicsLayer::SetContentsTo (
    this=0x3eb3188cda10, layer=0x846e1640c0)
    at ../../third_party/WebKit/Source/platform/graphics/GraphicsLayer.cpp:406
#2  0x00007f02f242496d in blink::GraphicsLayer::SetContentsToPlatformLayer (
    this=0x3eb3188cda10, layer=0x846e1640c0)
    at ../../third_party/WebKit/Source/platform/graphics/GraphicsLayer.h:210
#3  0x00007f02f2b345d2 in blink::CompositedLayerMapping::UpdateGraphicsLayerConfiguration (this=0x3eb3188c0fd0)
    at ../../third_party/WebKit/Source/core/layout/compositing/CompositedLayerMapping.cpp:790
#4  0x00007f02f2b56eaf in blink::GraphicsLayerUpdater::UpdateRecursive (
    this=0x7fffdd1fc608, layer=..., 
    update_type=blink::GraphicsLayerUpdater::kForceUpdate, context=..., 
    layers_needing_paint_invalidation=...)
    at ../../third_party/WebKit/Source/core/layout/compositing/GraphicsLayerUpdater.cpp:110

Re-categorizing as a compositing bug for further triage.

Comment 3 by schenney@chromium.org, Jul 17 2017

Labels: PaintTeamTriaged-20170717 BugSource-User
Status: Available (was: Untriaged)

Comment 4 by junov@chromium.org, Jul 18 2017

Cc: brajkumar@chromium.org
 Issue 745103  has been merged into this issue.
Project Member

Comment 5 by sheriffbot@chromium.org, Jul 19

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 6 by schenney@chromium.org, Jul 19

Status: Available (was: Untriaged)
►

Sign in to add a comment