Model Viewer crashing Google Chrome on some devices

[aviggiano]

Description

We have implemented the Model Viewer on an e-commerce's website and some users (2 out of 10) are experiencing a weird bug where the browser seems to crash (black screen) and recover after a short while. The model does not appear after downloading, but we can see only the "drag to rotate" icon indicating that the 3D should've been there.

I am not sure how to reproduce it, since our QA have tested the same URL on multiple devices (using browserstack and crossbrowsertesting) and none of them had this problem.

Live Demo

• Live demo - click the "Visualizar 3D" button and wait for it to appear
• Recording of the bug

Browser Affected

• Chrome - version 79.0.3945.130
• Edge
• Firefox
• Helios
• IE
• Safari

OS

• Android
• iOS
• Linux
• MacOS
• Windows

Versions

• model-viewer: v0.6.2
• three.js: v0.105.2

[cdata]

@aviggiano thanks for reporting this issue!

I have not reproduced that issue yet, but from a visual inspection that sure does look like a bad crash. It looks like the whole tab is crashing and recovering 😳

If I were to speculate, I would say it is likely that the WebGL context is being lost as part of the crash. We do dispatch an error event when we detect that the WebGL context is lost, which would give you an opportunity to recover from the crash (switch to a static image, notify the user etc). You can listen for it like this:

<!-- Somewhere on the page: -->
<model-viewer id="modelViewer" ...></model-viewer>
<!-- Later on: -->
<script>
modelViewer.addEventListener('error', (event) => {
  const {type} = event.detail;

  if (type === 'webglcontextlost') {
    // WebGL crashed, do something to recover!
  }
});
</script>

[cdata]

@aviggiano You mentioned that you have not been able to reproduce the bug. How did you collect that recording of the bug?

[aviggiano]

@cdata our client's user recorded their screen, but using our own devices we can't reproduce it.

[cdata]

@aviggiano thanks! Do you happen to have any more specific details about the client's user's device? Windows version, any hardware details, etc?

[cdata]

@aviggiano also, if possible, it would be really helpful to get the reporting user to do this:

1. Go to chrome://gpu in their Chrome browser
2. Copy the report to clipboard
3. Send the copied report to you so you can share it here

The report looks like this (taken from my own laptop):

Data exported | 2020-02-24T19:07:33.038Z
-- | --
Chrome version | Chrome/80.0.3987.116
Operating system | Mac OS X 10.15.3
Software rendering list URL | https://chromium.googlesource.com/chromium/src/+/dc00a510e4c2ae25c4d084cc3d946fc782249224/gpu/config/software_rendering_list.json
Driver bug list URL | https://chromium.googlesource.com/chromium/src/+/dc00a510e4c2ae25c4d084cc3d946fc782249224/gpu/config/gpu_driver_bug_list.json
ANGLE commit id | 362168eb695d
2D graphics backend | Skia/80 97c9a95908bc8c7a6794259b35f366a3291e2d0f
Command Line | /Applications/Google Chrome.app/Contents/MacOS/Google Chrome --flag-switches-begin --flag-switches-end --enable-audio-service-sandbox

[cdata]

Ping @aviggiano if you aren't able to get chrome://gpu details, that's fine. But, it would go a long way towards helping us to diagnose this issue. Thanks!

[aviggiano]

@cdata I'm scheduling a face-to-face meeting with the user that experienced the bug to get the report from them.

Are there any other tests that might be useful to diagnose this issue?
It would be better to do them all at once, since I'll be physically with the device that crashed. I was thinking about getting the Windows/device specs, but other than that I'm not sure how to debug.

[cdata]

I think chrome://gpu will be comprehensive enough for us. It will tell us what we need to know about the hardware of the device in question.

Ultimately what we need to be able to do is have a comparable hardware device to try to reproduce the crash on. Otherwise, we can only speculate about what is causing the problem.

[aviggiano]

@cdata sorry for the late reply, here's the report from two devices that had this issue:

• Report 1
• Report 2

In addition, we performed a couple more tests that may help you diagnose this issue:

1. We asked the user to try a different 3D viewer (by Sketchfab) with the same 3D model, and it did not crash
2. We asked the user to try a different 3D model with the same 3D viewer (this repo's model viewer) and it did crash, but after recovering the user was able to see the 3D model all in black (differently from our 3D model in production, that was nowhere to be seen after the recovery)
3. We asked the user to try with different browsers and when they used Microsoft Edge it did crash

Please let me know if we can do anything to help solve this problem.
Also, let us know if we can somehow detect the device's compatibility and only show the model-viewer to the ones that are compatible.

[ronpadz]

In the past, I've been able to address this on machines with older graphics cards by turning off Chrome hardware acceleration. (Settings >System >Advanced >System >Use hardware acceleration when available). Beware, this has potential to affect Chrome performance though.

[elalish]

@aviggiano This looks like a GPU driver bug of some kind. Interestingly, both of those cases report a Windows version almost two years out of date: Win10 April 2018 update. It's entirely possible Windows has fixed this in the meanwhile. I know it's a lot to ask, but could you suggest your user perform an OS update and see if that fixes the problem? I won't be able to do much on my side until I find a physical machine I can repro on.

[aviggiano]

@elalish Thank you for the response.

Indeed since we are not in direct contact with them (they are e-commerce users from our client), I'm not sure if we'll be able to ask them to update their OS. I'm already happy that we managed to get the GPU report 😆

Anyway, this will only help us diagnose this issue, but it will still happen to other people.
Is there anyway to detect the device's compatibility before including the model viewer? That would at least mitigate the UX problem.

Thanks

[elalish]

@aviggiano Yeah, I kind of figured as much. Thanks again for the GPU reports. Device compatibility is tricky; if it was just a missing GL extension we could check ahead of time, but this is just a bug. If we got enough data to figure out the scope of where it occurs, you could screen it with navigator.userAgent and some GL support fingerprint, but that seems kind of unlikely.

At least your can listen for our error message; if detail.type is webglcontextlost then at least you can fix things after the error (and log some info to find out where this is occurring). Hopefully that can happen before the crash does. Meanwhile the crash reports will make it back to Chrome, and perhaps they'll find a bug.