Error in WebGL does not get communicated

[LeanderK]

(I have created a new issue and not appended it to #2543, because I think this is rather severe)

Safari produces a WebGL error, which results in an empty graph. Plotly should no behave like this and instead communicate that something went wrong while trying to plot the data.
Because people might rely on plotly.js to communicate information and draw conclusions, I think this is important to fix and independent from the actual WebGL-fix.

[etpinard]

Hmm. I'm not sure about this one. Is there a robust way to do that? Do you have an idea what other WebGL libs (e.g. three.js) do in cases like this? We don't communicate SVG errors either (one ex: #2482)

[LeanderK]

looks like i never encountered a svg-error!
If I (or somebody else) uses plotly.js to implement for example a dashboard that visualizes important information and due to a webgl-error the graph is just empty, it might lead to the person drawing the wrong conclusions. Especially when an empty graph is a possible result (for example if I want to plot only the outliers of a dataset).
I think the result of plotly.js should be either a trustable visualization or an error.

I don't know the details and whether this is easy to implement, but this makes me not trust plotly.js, because I have at least one possibility where the information presented is just false and misleading.

[alexcjohnson]

@LeanderK I wholeheartedly agree with your sentiment here - any error that leaves the plot in a state that looks plausible but is in fact either missing or misrepresenting data must be a high priority for us to fix.

The challenge with communicating (visually on the plot itself I gather, as you already have this indication in the console) is that some errors don't seem to be accessible from javascript, as far as I can tell. I've seen that with some of the DOM errors during SVG rendering, haven't really looked into it for WebGL but wouldn't be surprised if the same is true of some errors there, given how separated it is from javascript processing.

With that in mind, we have four potential classes of bug:

• Those that throw an error, accessible from javascript, late enough that the plot looks plausible but is in fact wrong
• Those that throw an error early on, halting execution, so the plot is obviously incomplete
• Those that throw an inaccessible error, like the DOM errors I mentioned above
• Those that throw no errors, we just have a logic error or hit an unanticipated edge case

Only the first class would be helped by visually reporting the error (the second we could report but the user already knows there's a problem), while the last class accounts for the majority of bugs we deal with. So I worry that if we were to visually report, it would not only miss most bugs but if users expected to see such a report they would be less likely to notice the bugs that don't show such a report.

[alexcjohnson]

Closing - thanks for the fruitful discussion @LeanderK