Custom Aw-snap screen?

[Patrick Stinson]

Is there by chance a way to customize the "Aww snap!" screen? We are
using chrome for kiosks, and we would like to find a way to avoid
saying this and instead just reload the current url.

Thanks!

[Lei Zhang]

Or better yet, Chrome should not crash. Is there something in
particular that's causing sad tabs for you? If so, please file a bug.

http://dev.chromium.org/for-testers/bug-reporting-guidelines/reporting-crash-bug

> --
> Chromium Developers mailing list: chromi...@chromium.org
> View archives, change email options, or unsubscribe:
>    http://groups.google.com/a/chromium.org/group/chromium-dev

[Ben Rockefeller]

Are you using Chromium as a frontend for kiosk or just as an
application? Either way, if you have the ability to recompile Chromium
then you can for example for Linux edit this file to do your custom
Aww snap:
http://src.chromium.org/svn/trunk/src/chrome/browser/ui/gtk/sad_tab_gtk.cc

If you want to simply reload the current url, then notice in the
bottom of the file there is a call to tab_contents_->OpenURL(). You
could do similar in Sad Tab GTK constructor to auto reload

[Peter Kasting]

On Wed, Feb 1, 2012 at 7:17 PM, Lei Zhang <the...@chromium.org> wrote:

Or better yet, Chrome should not crash. Is there something in
particular that's causing sad tabs for you? If so, please file a bug.

http://dev.chromium.org/for-testers/bug-reporting-guidelines/reporting-crash-bug

Not only this, but to return to the original proposal, the entire reason we don't auto-reload is that it's a bad user experience.  The page may be triggering a consistent Chrome renderer crash, in which case you have just spawned an endless loop of crash-reload that has who knows what deleterious effects on the rest of the browser.  Even if not, a crash + reload will generally lose the user's tab state.  When the user doesn't actually get to see that something went wrong, and instead just loses their playing video, form data, page scroll point, etc. with no warning, it's incredibly frustrating.

I strongly suggest you not do this.

PK

[Patrick Stinson]

I dont have a specific case thats causing a crash. But, we are using chrome in kiosk mode in museum exhibits, and can't have the user seeing "awww snap!" if something goes wrong. It wouldn't look good professionally. Also, in the relatively unlikely event that it crashes reloading our custom interactive would be the desired recourse. Being able to customize the error handling would make sense here.

[Dominic Mazzoni]

Wouldn't it be possible to write a Chrome extension that reloads any tab that crashes?

There's probably a better solution, but the first one that comes to mind is that a content script "tickles" the background page every 100 ms, then if the background page doesn't receive a response from a particular tab before a certain timeout, it kills the tab and reloads its original url.

You would still see the "Aw, snap" page for a moment, but you could make it disappear before anyone figures out what's going on.

- Dominic

--

[Adam Barth]

Sounds like that would eat a lot of battery.

Adam

[Patrick Stinson]

This is a really, really good idea for a workaround if there isn't some kind of extension hook for the crash page.

[Mihai Parparita]

On Thu, Feb 2, 2012 at 12:03 AM, Adam Barth <aba...@chromium.org> wrote:

Sounds like that would eat a lot of battery.

Instead of polling the tab, you can use the chrome.tabs.onUpdated event to see whether it navigates to chrome://crash (per http://code.google.com/codesearch#OAMlx_jo-ck/src/chrome/common/extensions/docs/examples/extensions/fx/bg.js&exact_package=chromium&type=cs&q=chrome.tabs.onUpdated%20crash&l=10 it should work, but I haven't tried it myself).

Mihai

[Charlie Reis]

Tabs don't navigate to chrome://crash when they crash, do they?  I'm not sure if we have an extension API for detecting a crash yet, though it would be useful to have.

It would be a good reason to resume work on the Processes extension API, which is currently just experimental.  (See http://crbug.com/32302.)

Charlie

[Charlie Reis]

You would just listen for the OnExited event from the Processes API, which would indicate whether it was a crash or not.  I don't think we would say the tab's process ID is the browser's ID, but we should provide a way to find which tabs were affected by the crash.

I've been talking with Nasko about reviving work on this API, so we'll see if we can find time for it.

Charlie

On Thu, Feb 2, 2012 at 8:51 PM, Jesse Overton <je...@res3d.com> wrote:

They only return the chrome://crash URL if you've navigated there directly (using about:crash or chrome://crash).

To the best of my knowledge, crashed tabs no longer belong to their original process and will share a process ID with the browser. The Processes API's onUpdated event will list the browser's PID, so in theory one could use getProcessIdForTab and compare with the browser's PID to test for a crash.

Jesse O.