3D transformed animated element is not rendered, if it is initially not visible, and clip-path is set
Reported by
threejs....@gmail.com,
Mar 14 2018
|
|||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.146 Safari/537.36 Steps to reproduce the problem: 1. Open the attached html file 2. Refresh the page, and do not move the mouse 3. Only the initially visible faces of the cube will be rendered What is the expected behavior? What went wrong? The rendering of the faces (where clip-path is used) is only triggered, if the element changes or there is a mouse-event while it is visible. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 65.0.3325.146 Channel: n/a OS Version: 10.0 Flash Version:
,
Mar 16 2018
,
Mar 16 2018
Able to reproduce this issue on reported version 65.0.3325.146, on latest stable 65.0.3325.162, on latest beta 66.0.3359.33 and on latest canary 67.0.3372.0 using Mac 20.23.3, Windows 10 and Ubuntu 14.04. Good Build: 65.0.3312.0 Bad Build: 65.0.3313.0 You are probably looking for a change made after 527413 (known good), but no later than 527414 (first known bad). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/7205a0d557dce9a56444ba5660e302aeeaa18b55..fc25706df1a4e7ee35bcd3623a33a30ea837199e Reviewed-on: https://chromium-review.googlesource.com/848414 Suspecting same from changelog. @ trchen: Please confirm the bug and help in re-assigning if it is not related to your change. Adding RB-Stable for M-65. Please remove if not the case. Thanks!
,
Mar 16 2018
Removing the blocker because clip-path has always been broken until I recently rewrote it.
,
Mar 16 2018
Nevertheless, let's mark this as blocking M66.
,
Mar 16 2018
Marking as "M66" stable blocker per comment #7.
,
Mar 19 2018
I confirm this still repros as of latest beta (M66) release. It doesn't look like an invalidation issue since there is no repaint happening. It seems to be stale backface determination on mask layers. I can repro the same issue on older milestones with a slightly modified test case (changing clip-path into -webkit-mask:linear-gradient(black, transparent)). A simple fix may be possible. Investigating.
,
Mar 20 2018
It doesn't even need to involve mask layers. As long as there is an effect that creates render surface the bug shows up. Reassign to cc team for further investigation.
,
Mar 20 2018
Passing to flackr@ to find an owner for this.
,
Mar 26 2018
Still we are seeing the same issue on latest canary-67.0.3379.0 ,beta-66.0.3359.45 & dev-67.0.3377.1 as per C#0 & 10. flackr@, Please take a look into this as it is marked as RBS. Thanks..!
,
Mar 26 2018
Xianda, can you take a look? Given that clip path has always been broken (comment #6) and was "broken" in 65, I suspect this does not need to block 66.
,
Mar 26 2018
Looking at the bug.
,
Mar 30 2018
Do we have further update on the fix?
,
Apr 2 2018
Just a heads up, M66 Stable cut is on April 12th, 10 days away. This issue is marked as RB-Stable for 66. Please make sure to address this issue prior to stable cut. Thanks!
,
Apr 9 2018
Friendly ping to get an update on this issue as it is marked as stable blocker & M66 Stable cut is on April 12th. Thanks..!
,
Apr 9 2018
Reminder: Please note that M66 Stable is only 7 days away. This bug has been marked as ReleaseBlock Stable for M66. So please take a look and appropriately address this bug.
,
Apr 10 2018
Since this is not a regression, remove the release-block label.
,
May 24 2018
This bug has been around since at least M-53 as per trchen's repro in #10. Removing regression label since I have yet to find a point in time at which this has ever worked. Xianda, do you have any update for what causes the invalid backface check?
,
Jun 5 2018
Do you have any update on the issue? |
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by viswa.karala@chromium.org
, Mar 14 2018