www.google.com - see bug description

[reinhart1010]

URL: https://www.google.com/logos/2014/rubiks/iframe/ Browser / Version: Firefox 48.0 Operating System: Ubuntu Problem type: Something else - I'll add details below

Steps to Reproduce 1) Navigate to: https://www.google.com/logos/2014/rubiks/iframe/

Expected Behavior: All Rubik's cube colors should be present.

Actual Behavior: Some of the blocks are blocked by black items (see attachment)

From webcompat.com with ❤️

[adamopenweb]

Thanks @reinhart1010. Maybe Firefox users just get the harder version? ;) I can reproduce this in Firefox 49 & 51 for OSX.

[webcompatreport]

Google gave firefox a broken rubiks, poor child lol

[reinhart1010]

What about testing the same site with older Firefox versions released in 2014? This was a 2014 Google doodle.

[adamopenweb]

Good point @reinhart1010. This actually works for me in Firefox 31 for OSX. https://ftp.mozilla.org/pub/firefox/releases/

[reinhart1010]

So this is clearly a regression in the current version. But starting on which version shows this regression?

[reinhart1010]

How about this bug? https://bugzilla.mozilla.org/show_bug.cgi?id=1113633 This bug is listed under Firefox 35 release notes, but closed as WONTFIX.

[denschub]

This broke in Nightly between 2015-07-22 and 2015-07-23, so this broke somewhere between 8e5c888d0d89 and 1f77b78797d6. Sadly, we don't have old push builds available for bisecting, so someone would need to manually bisect and build to get the exact regressing commit...

[karlcow]

On the current Nightly I get at a point a freeze of the browser, in addition to the missing tiles.

There is something which is without any actions eating up memory.

Apart of the interesting challenge of understanding the issue, I'm pretty sure the chances to have this code modified is close to 0.

[karlcow]

It also could be they use a version of threeJS

/**
 * @license
 * The MIT License
 *
 * Copyright (c) 2010-2012 Three.js authors.

[…]
// three.js - http://github.com/mrdoob/three.js
var THREE = {
  REVISION: '66'
};

which is too old or was relying on a specific issue in Gecko.

The current version is 81.

[miketaylr]

It also could be they use a version of threeJS

The site in question is just modifying the DOM, so threejs (a webgl library) is probably unrelated. This is more a question of handling 3d transforms.

[miketaylr]

@denschub can you bisect that range further please?

[MDTsai]

I compare nightly firefox of mozilla-central-debug, in build ID 20150917152353 is good but in build ID 20150918140234 is bad. Now trying to find the exact commit broke this page.

[denschub]

@MDTsai See https://github.com/webcompat/web-bugs/issues/3273#issuecomment-249618469... it broke on 2015-07-22, I've just verified that yesterday again. However, we don't have push builds for that anymore, so I need to bisect that locally, but it turns out you cannot compile that code with the most recent llvm, so I need to downgrade for that.

[denschub]

Yikes. So, this broke first on 2015-07-22, then it got fixed. Then it broke again, then it got fixed again. Finally, it broke again and I've traced this down to the regressing bug. Quite a trip there...

Filed bug 1319683, closing this as a dupe. Thanks again for the report, @reinhart1010.

[karlcow]

Just for the paper trail. https://bugzilla.mozilla.org/show_bug.cgi?id=1319683#c5

The layer sorting code is currently getting completely rewritten (and the old code is getting removed) along with plane splitting implementation. The new sorting code should fix most issues like this. I'm hoping to get some of it landed within a next couple of weeks.

And the bug was closed as a duplicate of Bug 689498 - Intersecting planes are not z-ordered properly (need to implement plane splitting for CSS 3d transforms)