On 7/5/2014 8:21 AM, David Rajchenbach-Teller wrote:
Could we redesign this as follows?
1. Something goes wrong in the code of Firefox;
2. Firefox dies;
3. Crash report is stored to disk, without any dialog;
4. If the crash happened during Firefox shutdown, do nothing, otherwise
restart Firefox to its previous state (obviously, we need some measure
to prevent this from looping);
5. Upon the next restart, display a bottom doorhanger on all windows
"Firefox or an add-on encountered a problem [a few seconds ago / on July
4rd, 2014] and recovered. If you wish, Firefox can report it
automatically so that we can fix the bug <report/not this time/always
report/never report>."
Yes, we should do something like this.
It's not what we're going to focus on right now, though. Here's the
current plan:
* measure crash submission rates in FHR. Bug 994707 and 994708.
* implement the support-after-crash project so that we can provide
actionable results to users after a crash, based on their crash
submission. This is a Q3 project that Birunthan is working on
(https://docs.google.com/document/d/1dZkkjDh87k4UH4Gcv_gA_pkTo8yIR88l_Dxs2fXKJRs/edit?usp=sharing),
and is very intertwined with the project to improve automatic user
support for non-crash issues such as unwanted addons, incorrect
settings, and failure to update
* Explore some better UI options for crashes. Implement various options
and measure the actual crash submission rates we get.
We may need to go back and revisit some decisions we made in 2007 about
how we didn't want an "always submit my crashes" option in the UI. We
may also need to improve our crash report server to for example accept
comments about a crash after it was submitted.
If we end up in a situation where we're trading off a seamless restart
flow versus crash submission rates, I'm not convinced that seamless flow
is the correct choice. But we don't know yet what the options are or
what user behavior will be. That's why the submission rate measurements
are so important.
On 7/8/2014 12:23 PM, Justin Dolske wrote:
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.
Content-process crashes will be similar to how plugin crashes currently
work, and crash submission will be handled in-frame. To the extent that
crashes are caused by memory or other similar issues, we do expect most
crashes to be in content processes; but there's the whole class of
crashes which are caused by Firefox extensions/other 3rd-party
software/malware which are likely to remain in the base Firefox (chrome)
process.
--BDS
_______________________________________________
dev-platform mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-platform
