After breakpad integration is hooked up, we'll need an easy way to allow users to access about:crashes to be able to find a link to their crash report containing the crash information you normally see in socorro.

Andy's hack in webapp.json revealed that about:crashes can be accessed with the web runtime, as I saw this message. Submitted Crash Reports This application has not been configured to display crash reports. The preference breakpad.reportURL must be set. Most likely, we just need to allow the web runtime to have access to about:crashes by default (maybe in that allowed origins field?). Then, we just need a way to access it (keyboard shortcut?).

Does firefox's about:crashes show the crash reports from the runtime?

Unless they're being written to the Firefox "Crash Reports" dir, then no, they won't. I'm assuming the runtime uses a different profile location, so that wouldn't be shared.

I can imagine a hidden test/debug mode, triggered by a command-line flag, that provides some chrome, like a toolbar, that gives access to about:crashes in a new window (and also provides other useful functionality, like debugging tools). But we should not expose it normally, especially not via a keyboard shortcut, which would be very confusing to a user who accidentally presses it; and which are conventionally controlled by the app or the OS, not any runtime the app happens to be using.

(In reply to Myk Melez [:myk] [@mykmelez] from comment #4) > I can imagine a hidden test/debug mode, triggered by a command-line flag, > that provides some chrome, like a toolbar, that gives access to > about:crashes in a new window (and also provides other useful functionality, > like debugging tools). > > But we should not expose it normally, especially not via a keyboard > shortcut, which would be very confusing to a user who accidentally presses > it; and which are conventionally controlled by the app or the OS, not any > runtime the app happens to be using. Agreed. That sounds generally probably the best way to go all-around, including debugger tools - a mode to run in developer mode with the web runtime, although I'd be curious to hear what Kevin's opinion is on this. That should include access to about:crashes. On some thread with Kairo, I recall his idea of allowing about:crashes to be an installable web app, so that's another idea - even one we wouldn't have to do too much work on our end, but I'm not sure we need it. We'll really determine if we need this implemented if you can't view crash reports for the runtime within desktop firefox in a friendly UI.

(In reply to Myk Melez [:myk] [@mykmelez] from comment #4) > I can imagine a hidden test/debug mode, triggered by a command-line flag, > that provides some chrome, like a toolbar, that gives access to > about:crashes in a new window (and also provides other useful functionality, > like debugging tools). > > But we should not expose it normally, especially not via a keyboard > shortcut, which would be very confusing to a user who accidentally presses > it; and which are conventionally controlled by the app or the OS, not any > runtime the app happens to be using. I personally don't like command line flags (as a permanent solution). What if we had a pref that could be set from within Firefox to turn on development mode for an installed app? If that pref was set, we could add a native menu for development-related features.

I agree with Kevin on the command line flag piece. I feel we should surface something more usable in the existing developer tools section of Firefox's global menu. It could start simple, perhaps a checkbox entry labeled "Enable Developer Tools in Apps" that activates a developer tools menu across all apps.

Hmm, indeed, a pref you can set in Firefox seems more usable than a command-line flag.

Per bug 1238079, we're going to disable the desktop web runtime and remove it from the codebase, so we won't fix these bugs in it.