The first iteration of the plugin-crashed UI (from bug 538910) strove to implement a UI that minimized user interruption / decision-making. The thinking was it informed the user what it did, provided links to how to change it, but was otherwise something that felt ignorable and non-disruptive. Per some recent discussions, this isn't quite the right way to meet its goals while still respecting user privacy. Some specific concerns are that it's more opt-out than opt-in, and should be clearer about if a choice will result in automatic future submissions (especially when interacting with the standalone crash-reporter).

I think a proper fix here will require the changes in bug 550303. [Which adds a "always do this" checkbox to the standalone crash-reporter.] So, the revised UI would be: * OOPP crash UI will default to having a "submit a crash report" link. * Prefs UI will have 3 states - ask me (default) submit automatically, never submit/ask. * OOPP crash UI should have a link to open prefs UI. * UI for the other states are "a report was submitted" and "crash reporting disabled." * 3-state pref shared with standalone crash-reporter (with bug 550303 changes). To deal with multiple instances of a plugin croaking, we'll probably need a way to update all the instances of the UI when a report is submitted. I was hoping to avoid this, but oh well. [This could be done as a separate step, it's not critical.] If we're concerned about string changes for the Lorentz backport, we can skip the 550303 changes there and simply make the OOPP crash UI always ask -- no automatic submission, no automatic don't-bug-me.

WIP. Inplements the UI from the last comment, but doesn't yet have the pref changes (so it's always in "ask me") mode.

Flagging vlad for review, as I think Gavin is still out this week. Updates the crashed-plugin UI as described in previous comments. I've left placeholders for adding code to allow automatic submission of crash reports, there are still a few UX decisions there wrt to the standalone crash reporter (which we might not want to take on Lorentz anyway?). As-is, this patch makes things always opt-in. Also did a few small things while I was here: * Added text for the case of a crash without a minidump * Added a "submit crash report" button to the notification bar. [This should also allow us the option of having the notification-bar UX bsmedberg wanted without strings impact.] * In-content UI shows live submission status in all instances of a crashed plugin, so that the user doesn't end up with stale "submit a report" links.

Comment on attachment 432498 [details] [diff] [review] Patch v.2 ...And r?ted for the CrashSubmit.jsm changes.

Comment on attachment 432498 [details] [diff] [review] Patch v.2 Looks fine, though I sure wish there was an easier/less wordy way to do a bunch of this stuff... the random dom node creation/manipulation is annoying from script.

Main suggestions from UX meeting: * Get rid of Prefs link (just make sure the SUMO article link has info regarding preferences) * Change "Learn More" to a help icon/glyph * Shorten submit text to "Report this problem" or something similar.

Comment on attachment 432623 [details] Screenshot of patch v.2 Changes we just discussed in the UX meeting: -remove preferences link (perhaps on a context menu?) -after submit show a checkbox [] submit automatically -replace "learn more" text with small (?) icon in the lower right corner. Single block of text: "The Shockwave Flash plugin has crashed, please _submit a crash report_. _Reload the page_ to try again."

Here's (In reply to comment #7) > Main suggestions from UX meeting: > > * Get rid of Prefs link (just make sure the SUMO article link has info > regarding preferences) > * Change "Learn More" to a help icon/glyph > * Shorten submit text to "Report this problem" or something similar. I'm attaching a mockup like dolske described. "Learn more" has been reduced to a glyph which links to a page that both the error and preferences, so the preferences link has been removed. For the reporting link, once the user actually submits a report, they are given the option to automatically do this every time (checked by default). It would be great if through this checkbox the user could actually change their preferences, thus not even needed to open a new dialog.

Boriss's mockup looks good, quick notes: -Submit Report in title case -native checkbox -avoid ! -"Automatically submit crash reports"

What is the behavior WRT the notification bar going to be? I'm still worried about users hitting refresh and not getting enough reports or a good sample.

Updated with feedback from UX.

(In reply to comment #11) > What is the behavior WRT the notification bar going to be? I'm still worried > about users hitting refresh and not getting enough reports or a good sample. Behavior is the same as what's already landed; no notification bar unless a page's plugin instance is too small to show the in-content UI. Alas, I think we're stuck here, since your concern and having non-intrusive UI are essentially at-odds. :-( The best I can offer is that if we add a "submit automatically" checkbox (ala Boriss' mockup, which I'd like to do), that helps *both* cases -- users who want to help won't have to deal with clicking "send crash report" each time, and thus we get a better sampling of plugin crashes. I did add a "Submit a crash report" button to the notification bar, though... So that should help preserve the option of making a late change to always show the notification bar. EG, Developer Preview 4 with this patch, watch the volume of crash reports, and if they drop off precipitously revisit the UI for the release after that. Else we should talk with UX + beltzner to see if there are other alternatives, or if we need to take a UX hit as the price of what's good for users in the long-run.

Comment on attachment 432903 [details] Screenshot of patch v.3 looks good, but I still want the 8-bit frown and isometric brick :)

Pushed http://hg.mozilla.org/mozilla-central/rev/c3a1a039bbb4

(In reply to comment #11) > What is the behavior WRT the notification bar going to be? I'm still worried > about users hitting refresh and not getting enough reports or a good sample. Would it be possible to save the report and submit it if consent is obtained later? I believe Windows behaves this way.

Do we want this on the lorenz branch? If yes, please land ASAP. The new plugin crash strings are now exposed to the localizers and since this patch is obsoleting some of them, landing this asap will avoid the localizers spending more time on these strings than is actually needed.

http://hg.mozilla.org/projects/firefox-lorentz/rev/d8fb76bbaefb http://hg.mozilla.org/projects/firefox-lorentz/rev/0eb165415b2f