Closed Zacqary closed 7 years ago
This looks oddly like #3273.
Yes very similar to the Google issue At least @Zacqary who reported the issue is the owner of the site.
Maybe it could help define a reduced test case showing the issue.
The rendering problems occur when the "front" faces of the 9 cubes in the middle turn visibility: visible
for the duration of the animation. Normally, the inner faces of each cube (i.e. the ones facing the inside of the Rubik's cube) are hidden
.
So I'm guessing it's a bug in how the rendering engine calculates which visible things are in front of other visible things, if too many things are close together.
If you look closely at the Chrome case you can see that it's actually doing something similar for one frame — watch the upper left corner of the Rubik's cube and you can see a bit of black flash where it's not supposed to for a single frame.
Chrome was running into this issue at the same magnitude when the .Puzzle
element had an opaque background-color
, but removing that made it look acceptable in Chrome. It's still definitely choking for a single frame though.
@Zacqary thanks for the context. I wonder if it's the same issue as https://bugzilla.mozilla.org/show_bug.cgi?id=726766
Let see.
@karlcow Re: your comment on the Bugzilla, I don't know if animation is relevant. While debugging the rendering issues in Chrome, I would run into one sometimes just from rotating the spinning cube section to a certain angle.
I've got a busy rest of the week and weekend so I'm not sure if I can help debug for a bit, but if you want to check out the project repo you can give yourself more freedom to work with it. In src/Puzzle/renderSlicedCubes.js
, if you remove the onAnimationEnd
prop then the markup and CSS won't go back to their un-animated states after the animation finishes, and you'll be able to play with the transform
s and visibility
s in the devtools more freely.
I am fairly confident that this is the exact same case as in Google's cube. The underlying issue is tracked in bug 689498. Let's keep it open and test whenever the fix for that lands.
It would appear that this has just been fixed in bug 1286716, as my Linux and OSX machines are now rendering the cube as I would expect.
@Zacqary, can you try this again on an updated nightly and confirm?
Yep, can confirm it's working in the latest nightly!
Awesome, thanks for confirming!
URL: https://zacqary.github.io/rubix Browser / Version: Firefox 51.0 Operating System: Mac OS X 10.11 Problem type: Something else - I'll add details below
Steps to Reproduce This seems to be a bug with Firefox's rendering of 3D CSS transforms. Given a group of div cubes (a la the MDN CSS perspective example: https://developer.mozilla.org/en-US/docs/Web/CSS/perspective), the occluded faces of some of these cubes end up being drawn when they shouldn't be.
1) Navigate to: https://zacqary.github.io/rubix 2) Click any one of the small arrows to spin a section of the cube
Expected Behavior: An animation plays of that section of the cube spinning, without any of the black innards of the cube showing
Actual Behavior: The innards of the cube show during the animation
From webcompat.com with ❤️