webcompat / web-bugs

A place to report bugs on websites.
https://webcompat.com
Mozilla Public License 2.0
739 stars 63 forks source link

zacqary.github.io - see bug description #3406

Closed Zacqary closed 7 years ago

Zacqary commented 7 years ago

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

Screenshot Description

From webcompat.com with ❤️

denschub commented 7 years ago

This looks oddly like #3273.

karlcow commented 7 years ago

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.

Zacqary commented 7 years ago

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.

Zacqary commented 7 years ago

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.

karlcow commented 7 years ago

@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.

Zacqary commented 7 years ago

@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 transforms and visibilitys in the devtools more freely.

denschub commented 7 years ago

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.

wisniewskit commented 7 years ago

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?

Zacqary commented 7 years ago

Yep, can confirm it's working in the latest nightly!

wisniewskit commented 7 years ago

Awesome, thanks for confirming!