On 7/7/14 12:21 PM, Ehsan Akhgari wrote:
We should keep in mind that sometimes due to startup crashes, we don't get to run any of the code in Firefox, so we can't gate the crash report submission on that code at least in the case of startup crashes.
Yes. For that, I think we'll need to retain an independent fall-back crash reporter as we have today. But being able to handle the normal ("not a startup crash") case in-product would be nice for a number of reasons. I had talked with some folks a long time about about doing something similar to what David is proposing, so I think it's generally a good idea!
1) Crashes suck and are disruptive for users. Making that less painful by minimizing the impact (e.g. trying to restart and recover as seamlessly as possible) is a win in general.
2) Being able to integrate the crash-submission flow into the browser opens up possibilities for better UX and features, since it's the familiar cross-platform environment we all work in. (Currently the crash reporters are per-platform native apps, which I think is a big part of why they've been unchanged and unpolished for years). One can envision, say, a flow where the submission results in a guided troubleshooting experience, especially when the signature matches something we know has been fixed or has a workaround/solution.
3) E10S will already need something vaguely like this, since a content-process crash won't take down the whole browser. (And having the native crash report pop up would be weird.) I'm not sure if we know what the content-vs-chrome breakdown will be for all crashes with E10S, but I'd sorta assume content crashes would be more common, and that UX flow will be the one seen more frequently by users.
Justin _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
