Zoom Crash from Touch Input on Viewer Initialization

[austin-clifton]

After initializing a viewer, if any zoom touch events occur before a pan (rather difficult to gesture a zoom before a pan with touch, but doable), a render error occurs and causes the viewer to crash.

Here is a link to a Gist page with code that can be used to reproduce the error (a touch input device is needed, or some ability to emulate touch events):

https://gist.github.com/amc723/508009b296ca4783f7a55eb57e038ac6

[emackey]

Interesting. Not sure if this is the same issue but I can get a similar crash with un-panned mouse-zoom starting from the upper-left corner (0,0) as mentioned in your gist. Here are my reproduce steps:

1. (Re-)load the Cesium Viewer page (possibly from any valid view, the default view works if your screen is 1080 pixels tall, closer views will reproduce more quickly). DO NOT pan after loading.
2. Click the full-screen button (so that 0,0 is easy to reach with the mouse in the next step).
3. Starting from the far upper-left corner, click and hold the right mouse button, and drag slowly straight down.
4. After Cesium crashes, hit ESC to get out of full-screen, and check your URL.

The result is Cesium crashes the render loop with Invalid array length. But the more interesting observation can be made on the address bar after leaving full-screen mode:

.../Apps/CesiumViewer/index.html?view=NaN%2CNaN%2CNaN%2CNaN%2CNaN%2CNaN

Clearly the camera has moved into NaN territory.

[willemvdg]

+1

[lucasvw]

+1

[mramato]

Clearly the camera has moved into NaN territory.

@emackey the issue for your use case is that _zoomWorldPosition in ScreenSpaceEventHandler ends up being 0 and then gets normalized which results in the NaN. You can see this yourself by adding the below check to Cartesian3.normalize just before the return.

        //>>includeStart('debug', pragmas.debug);
        if (isNaN(result.x) || isNaN(result.y) || isNaN(result.z)) {
            debugger;
        }
        //>>includeEnd('debug');

I think this points to your issue and the original issue being the same thing, but I'm not sure what the fix is. Perhaps @bagnell has some thoughts.

We really need to get #3605 into master, as it would have caught this way earlier.

[smills2929]

Seems to be the same as this: #4440

[hpinkos]

Yes, it does seem like it's likely the same issue. We were never able to reproduce it with a mouse before so it seemed to be touch specific. Thanks for providing us with all the details @smills2929!

When we fix this, we'll just double check to make sure #4440 is fixed as well.

[pjcozzi]

Is someone able to look at this today at the bug bash?

[emackey]

I'm looking at touch/pointer events in general today.