the __google-debug__ query string sets the initial angle to the problematic value and sets the rotation of the top face of the panoramic cube to -90deg

I am able to reproduce the bug using the URL http://youriguide.com/sample-full?__google-debug__ (completely white screen, see screenshot) on Mac OS X 56.0.2924.76 (64 bit) but not on Mac OS X 58.0.2999.0 (64 bit).

Hopefully whatever underling issue there is has been fixed, but marking Needs-Bisect so we can identify the specific CL and confirm.

Deleted: M58_cannot_reproduce.png 738 KB

	M58_cannot_reproduce.png 738 KB View Download

Deleted: M56_reproduction.png 168 KB

	M56_reproduction.png 168 KB View Download

Tested the issue on MacBook Air-10.12.2 and MacBook Pro(Retina)-10.12.1 using chrome versions 55.0.2924.76 , 55.0.2883.95, 56.0.2924.76 ,stable version-56.0.2924.87 and canary 58.0.2999.4 with the url http://youriguide.com/sample-full?__google-debug.
Observed that the issue is not reproducing consistently.
Please find the attached screencast and let us know if anything missed here to reproduce the issue.

Thanks..

Deleted: 55.0.2924.76-686873.mov 9.7 MB

55.0.2924.76-686873.mov 9.7 MB Download

The viewer is made to resize itself when the window is resized. I did notice on my computer that the issue was happening at different window sizes. However, on my collegue's computer it was consistently happening everytime. It also was giving this result to some of our clients viewing this property, set at this initial viewing angle.

Thanks

I can confirm sureshkumari@'s findings on inconsistent reproducibility - I can no longer reproduce on my Macbook Air that I used just yesterday (still 56.0.2924.76 (64 bit)) :(.

cc-ing a few folks that may have some ideas on reproducibility or possible root cause.

Maybe related to decomposing the matrix at 90deg. We have a bug on that: crbug.com/681408

+vmpstr this looks a lot like the freeze we saw in  issue 678432 . In particular refreshing the tab no longer shows the loading spinner unless you open it again in a new tab.

Here (http://codepen.io/fsuna064/pen/ggdNbY) is a codepen where I have isolated the cube.

The cube's transform is applied:
- on page load
- on window resize

The problem occurs on page load or on window resize at certain window sizes.

Also, another of our properties had the issue even after the fix. It occurs at another angle (0.7853981633974483rad). This time it seemed to occur on my Mac and my collegue's but not on another collegue's Windows computer. Again, no issues on other browsers.

To observe the issue, replace
var rotateHorizontal = '';

with
var rotateHorizontal = 'rotateY(0.7853981633974483rad)';

or
var rotateHorizontal = 'rotateY(2.356194490192345rad)';

Thanks

The code in #11 consistently reproduces the problem in stable, but does not reproduce the problem in tip of tree.

The fix referenced in #10 initially made it in 58.0.2988.0, which is the current dev version.

Could you try using either dev or canary channel to see if the problem is fixed there? Meanwhile I'll take a look to see if the patch is simple enough to be merged to 57. I'm pretty sure we're out of luck for 56 though. 

I can confirm that the issue in #10 and #11 seems to be fixed in Chrome Canary 58.0.3007.0.

Any info on when this fix will be available on the stable Chrome?

By the way, we applied a temporary fix by initially rotating each of the cube faces by a value near 0, 90 or 180 (0.0001, 89.9999, 179.9999) deg.

It seems to fix it for many different angles, however I am not sure why this should happen.

I took a look at issue https://bugs.chromium.org/p/chromium/issues/detail?id=678432 and understand that in that case the issue had to do with the skew matrix having a tan(90deg) which gives a value of infinity.

In our case, looking at the way w3c specifies the calculation of the rotation matrix (https://www.w3.org/TR/css-transforms-1/#recomposing-to-a-3d-matrix) I don't see a case where there would be a division by 0 caused by sin or cos of the given angle.

Does our fix make sense? If so, why does it work? Otherwise what can we do to fix this temporarily?

Thanks

Should this issue be dup'ed against  issue 678432 ?

The problem in our code was that we were using a very large rect to accumulate damage (the portions of the screen that need to be redrawn). However, due to int limitations we ended up with a rect that was offscreen and large enough that adding any other rects to it didn't change it. So in the end although the page was "technically working" no visual updates would present themselves which gave the appearance of a hang.

I suspect that your fix just avoids "bad angles". However, since it's a combination of the face rotation and the cube rotation, I also think that if you change the face rotation there will still be a cube rotation angle that will cause the hang. 

The problem face is the top face I believe, which ends up having (I changed the container to be 500px by 500px):

perspective: 250px
perspective-origin: 250px 250px;
transform: translateZ(250px) rotateY(2.35619rad) rotateX(-90deg) translateZ(-251px);


So the computed transform is:
matrix3d(
  -0.707107,     0,          -0.707107,    0,
  -0.707107,     6.12323e-17, 0.707107,    0,
   4.32978e-17,  1,          -4.32978e-17, 0,
  -1.08677e-14, -251,         250,         1
)

I think when we invert that to compute damage, we end up with very large rect. I'm not too sure what you can do as a work around to be honest. Maybe not displaying all faces when you know some of them will be occluded by faces in front, but that might be hard or inconvenient to do.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4199618e79323f620735b60e833bdc77bca3c77c

commit 4199618e79323f620735b60e833bdc77bca3c77c
Author: Vladimir Levin <vmpstr@chromium.org>
Date: Thu Feb 09 20:22:47 2017

cc: Ensure that large damage doesn't register as "frame has no damage"

When we have accumulating damage from really large or really far rects
we can't union them correctly. So instead, introduce a DamageAccumulator
that detects this and an additional function ShouldDamageEverything
that ensures that if we run into this situation, we just damage
everything we can.

R=danakj@chromium.org, enne@chromium.org
BUG= 678432 ,  686873 
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

Review-Url: https://codereview.chromium.org/2632463005
Cr-Commit-Position: refs/heads/master@{#445208}
(cherry picked from commit efb8e7ef70d18b7380210e7244113653ab41cf42)

Review-Url: https://codereview.chromium.org/2683113003 .
Cr-Commit-Position: refs/branch-heads/2987@{#414}
Cr-Branched-From: ad51088c0e8776e8dcd963dbe752c4035ba6dab6-refs/heads/master@{#444943}

[modify] https://crrev.com/4199618e79323f620735b60e833bdc77bca3c77c/cc/debug/debug_rect_history.cc
[modify] https://crrev.com/4199618e79323f620735b60e833bdc77bca3c77c/cc/layers/render_surface_impl.cc
[modify] https://crrev.com/4199618e79323f620735b60e833bdc77bca3c77c/cc/layers/render_surface_impl.h
[modify] https://crrev.com/4199618e79323f620735b60e833bdc77bca3c77c/cc/trees/damage_tracker.cc
[modify] https://crrev.com/4199618e79323f620735b60e833bdc77bca3c77c/cc/trees/damage_tracker.h
[modify] https://crrev.com/4199618e79323f620735b60e833bdc77bca3c77c/cc/trees/damage_tracker_unittest.cc
[modify] https://crrev.com/4199618e79323f620735b60e833bdc77bca3c77c/cc/trees/layer_tree_host_impl.cc
[modify] https://crrev.com/4199618e79323f620735b60e833bdc77bca3c77c/cc/trees/layer_tree_host_unittest_damage.cc
[modify] https://crrev.com/4199618e79323f620735b60e833bdc77bca3c77c/cc/trees/layer_tree_host_unittest_video.cc

@14, we just merged this to 57, so whenever that becomes stable, the fix should be there.

Tested the issue on Mac-10.12.2 using 57.0.2987.54 as per the comment#0.

Observed that the fix is working as expected.

Attaching screen cast for reference .

Hence, adding the verified labels.

Thanks.

Deleted: Mac-686873.mov 5.1 MB

Mac-686873.mov 5.1 MB Download