[UX] Tab crash page

[lime124]

Requirements:

1. New copy for the description since we're saving history and not a private browser
2. How "restoring" a session should look (likely a restore session button similar to close tab, with copy that reflects this)

There's also this question: #1003 (comment)

┆Issue is synchronized with this Jira Task

[brampitoyo]

Changed the issue name to reflect the fact that this error page appears only when a single tab has crashed – not when the whole app crashed.

[brampitoyo]

@sblatz Here’s a mockup for tab crashed page, along with copy that @mheubusch has written:

Inspectable mockup: https://mozilla.invisionapp.com/project/17050512

(Note that the illustration is still a placeholder, but the measurements are correct).

[sblatz]

@brampitoyo is <name> here the name of the user? If so, how will we know their name if they don't have an account?

(perhaps it's just "Fenix" in this case?)

[mheubusch]

Sorry - its the name of the product - it should be a shortname parameter thing since we know we can't go into MVP with the name Fenix so if we call it GeckoView Preview we'll need the ability to change it to Firefox when we move out of MVP into release.

…

On Thu, Mar 21, 2019 at 11:15 AM Sawyer Blatz ***@***.***> wrote: @brampitoyo <https://github.com/brampitoyo> is <name> here the name of the user? If so, how will we know their name if they don't have an account? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1102 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ATLxym06xv3M9THWIoM7bsq7ebX2A37yks5vY7AYgaJpZM4b_2QS> .

[sblatz]

Thanks for the clarification, I also don't seem to have access to that placeholder image (even when I do inspect mode, there's no asset), are you able to send it to me? :)

[mheubusch]

@sblatz did you get the asset you needed for restore tab? Also do you need a new user story/epic for restore session?

[lime124]

@mheubusch sean got him all the error page illustrations and strings on friday.

[sv-ohorvath]

@mheubusch Hello, it might be just me, but the crash message sounds like the tab can't be restored, although there's still a "restore tab" option.

#2: There's no "send crash report" option in the tab crash reporter. Is that intentional?

[mheubusch]

@sv-ohorvath not just you. :) Have someone on my team taking a fresh look at this - thank you. also, IICR we are handling crash reporting options in the settings, not at the page level but @brampitoyo can confirm.

[MeridelW]

Hi @sv-ohorvath! That copy has indeed been updated (see attachment for latest mock—still a work in progress...for example, button copy should be all caps). The user can indeed "try again" and the copy no longer contradicts this.

As for "send crash report," there is a separate prompt that comes up in the flow for the user to report an issue. This is the only error that has the reporting function as this is the only error that is Mozilla's fault.

[sblatz]

This page is currently being displayed when a tab crashes. GV team is working on a feature that would allow a tab to be restored after it has crashed, but right now we can only close it (or choose to reload the page without any history). I don't think a "try again" button being the only option is good, as it does not give a clear indication to the user that they may be forced to just close the tab to get out of the loop.

Do we want to change the behavior of "restore tab" to just reload the URL of the crashed tab with no history?

[MeridelW]

@brampitoyo Can you weigh in on this? What's the best way to give the user the option to close the tab? I agree we need this.

@sblatz What are the implications of reloading with no history?

[sblatz]

@MeridelW Essentially it would be like they had just started a brand new tab with that page loaded. This means their scroll position, any data entered, any previous history of browsing on that tab would be lost.

[MeridelW]

@brampitoyo What are your thoughts on this?

[brampitoyo]

@sblatz @MeridelW In earlier mockup, we have options for “Close tab” and “Restore tab”. Shall we use those?

“Restore tab” would make sense only if we can ensure that the tab won’t crash again (and go into a reload-crash-error-reload-crash-error… loop). Otherwise, “Close tab” is a safer bet.

Would starting a brand new tab without saving anything help fix this loop?

[sblatz]

@brampitoyo "Restore tab" could attempt to restore once, then would send us back to the same spot, but the user could then press "close tab". Keep in mind that this option is not yet available on the GeckoView side, so we could have "restore tab" just reload the tab's URL with no history, which, if it crashed again, would leave the user in a position to press "close tab" if they think they're in a loop.

[brampitoyo]

@sblatz OK. Let’s go with “Close tab” and “Restore tab”, then. This way, the user can try to recover (which is always a preferred option), and can close when recovery fails.

[brampitoyo]

@sblatz Please find the new tab crash design (the only change is the inclusion of two buttons: close and restore) here: https://mozilla.invisionapp.com/share/P7R8W1ZWHM6

[sblatz]

@brampitoyo After some more work on this, it seems we actually don't have the ability to reload the tab just yet. I will just use a "close tab" button for now, and will add the "reload tab" when this functionality is added by the GV team

[brampitoyo]

Paging @shorlander to review the design above.

[shorlander]

Looks good to me.

@brampitoyo I don't know if we have illustrations in these pages yet, but Sean says we should use fx-fenix_error_9.svg for this.

[mheubusch]

@sblatz just a reminder that the actual string is Sorry. can't load that page.

[brampitoyo]

@shorlander Thanks! Below is the updated mockup containing the latest illustration from Sean:

[vesta0]

@mheubusch I believe this can be closed?