Consistent styling for "Crashed" components

[nchevobbe]

In Bug 1551612 I'm adding a safeguard to make sure that messages that couldn't be rendered (because we threw an exception) don't crash the whole console output (known as White Screen Of Death).

My patch is very naive, and I display a message inviting the user to file a bug:

The Copy message metadata button allow to copy the data we couldn't render, which should make it easier for us to fix the issue.

This brought a few questions:

1. Potentially, the message could have some sensitive data. We could render the message data (it's a simple object) directly in the message so the user can check what's in there. The label can definitely better too.
2. The message has the same look as other error messages, which doesn't look ideal. Maybe we could have a common style of what a "crashed" component could look like? We could even be consistent with Firefox's UI

I guess it will be tricky to have a nice illustration in such small components, but maybe we can find something?

cc @digitarald

[nchevobbe]

We could have Devon somewhere :D

[fvsch]

With your patch, is the Console still working after encountering that kind of error? Can users still see new messages, type commands, etc.? If yes, your current approach might be best.

[nchevobbe]

With your patch, is the Console still working after encountering that kind of error? Can users still see new messages, type commands, etc.? If yes, your current approach might be best.

Yes, everything will work (except the message that crashed). But I'm more interested in how we could style the crashed message in a nice and Photon compliant way.

[digitarald]

@nchevobbe trying to understand how much effort we need to spend on optimizing this flow; how many users would we ever expect to see this and what creates messages that can not be rendered?

The low-hanging fruit is throwing these messages in the browser console and providing more context there; vs asking users in the content console to file bugs with copied raw data.

[nchevobbe]

if we'd have a goal, it'd be for the user to never see this message :D
But crashes happen, and we should have as much data as we can on our end to fix them.

what creates messages that can not be rendered

A server-side/platform change that isn't covered by tests yet, some data being different from what we assume them to be, … could be anything really.

The low-hanging fruit is throwing these messages in the browser console and providing more context there; vs asking users in the content console to file bugs with copied raw data.

I think most users don't know what the browser console is, and you have to check additional pref to enable it. The use case here is really to ensure we get precise bug report of what's happening, with data that can help us fix this.

I'm thinking of the console right now, but we had a few full panel crashes (e.g. in debugger), which:

• we should not have using componentDidCatch
• should be easy to report to us ("instead of "console is blank").

One of the crash we fixed for the console this week was there for a long time, and the user who experienced that (mozilla employee) didn't report (Brian happened to work with them at some point, and learned that browser console was broken on a given situation). So we can see that it's hard to get a report, and that's what I want to ease here (even if the crash will be less harmful now).

Does that make sense?

[digitarald]

One of the crash we fixed for the console this week was there for a long time, and the user who experienced that (mozilla employee) didn't report (Brian happened to work with them at some point, and learned that browser console was broken on a given situation).

Maybe we can work on backing up more of the assumptions here. If users don't report a bug for a completely crashed Console, why would they report an error message that causes a minor "We're sorry …" error?

[fvsch]

But I'm more interested in how we could style the crashed message in a nice and Photon compliant way.

My point was that the Photon designs you are referencing are used when the full page or tab is unreachable or crashed. They're called "System errors" in https://design.firefox.com/photon/patterns/errors.html

I think we already have an error message component that may appear between the Console output and jsterm? Not sure how it looks, but maybe we could use it as-is, or tweak it? That would keep those errors separated from errors logged in the Console and that come from web content.

If users don't report a bug for a completely crashed Console, why would they report an error message that causes a minor "We're sorry …" error?

Personally I don't report "blank panel" errors (I've had a few in Debugger, Console or Inspector) because it feels like there's no actionable information I could give, so what's the point? When a white panel happens, in my experience it feels random and I don't have any mental picture of the STR.

In those situations, if I was told "hey, we crashed because of this specific error, you can click here to copy the error data, and file a bug with that data", I would file those bugs. (Could this be automated? A la Crashlytics, Sentry, New Relic, etc. Might be a privacy concern?)

I'm also wondering if there is a point in providing this UI, but only on Nightly and Beta/DevEdition channels. The user population on those channels may be more motivated to report issues and less puzzled?