557661 - change out of process plugin crash UI to make it easier to submit crash reports

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Mike Beltzner [:beltzner, not reading bugmail]]

Users should be in control over whether or not they submit a crash report, but the current UI makes it hard for users to see how to do that as the option is stuck in the bottom right corner.

To make it easier to see that the preferred course of action is for a user to submit a crash report, we should change the UI ever so slightly. The "Submit a report" link should be in the main block of text, and the "don't send report" option should be at the bottom right.

After clicking on "submit a report" it should move to the bottom right while the report is being submitted and for confirming that the report was sent. Once the report has been sent, the main block should get the "Reload the tab to try again" line to re-inforce that this is the desired next step.

We can do this without any string changes, too!

Comment 1

[Mike Beltzner [:beltzner, not reading bugmail]]

Attachment: mockup of design in comment 0

Comment 2

[Justin Dolske [:Dolske]]

Swapping the position of the "click to submit" and "reload" text seems reasonable. I'm not so so about having them jump back and forth, though.

How about just always putting the "reload" text in the corner?

Comment 3

[Mike Beltzner [:beltzner, not reading bugmail]]

Yeah, swapping locations wasn't my first choice, but I'm trying to work within the set of strings we have :) 

I really want the "OK, I've submitted a crash report" to lead immediately into the next suggested action. I'll attach an alternate mockup that doesn't swap locations.

Comment 4

[Mike Beltzner [:beltzner, not reading bugmail]]

Attachment: alternate design

So, the deal is that I want the user to basically be able to click in the same place to:

 - first submit the report
 - then reload the page

This keeps the report submitting text in the same place, and just suggests that once we start submitting the report we remove the "Reload the page to try again" from the bottom right, and once we're done with the report we put it in a more prominent location.

The hit target for clicking should include the icon and the entire text block in the middle of the UI to make it easy.

Ideally, the user will click, wait a second, click again, and be back up and running.

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

Attachment: third option is best

Dolske pointed out that we can keep our opt-in nature and get rid of the jumpy ui by simply not putting anything (including baby!) in the corner.

I actually think I like this design best. It encourages people to submit crash reports, and even if they don't, they can always close the tab on the crashy flash application. The only downside is that some users may wonder if this means they can't reload the tab without submitting a crash report.

My suggestion would be to implement this, and we can change based on feedback if needed.

Comment 6

[Julie Martin]

I have chatted with Mike and am okay with this design.  We need to have the privacy policy easily available to folks and ideally it would be on the initial UX with a check box opt-in.  Over time, we need to be moving in this direction so please keep it in my mind in future revs so we can try to incorporate it in as UX-friendly a way as possible.

For now, we have agreed to put the privacy policy link in the language underlying the question mark link.

Mike believes all the current language in the Firefox PP for crash reports covers this.  I am going to paste it in this bug and get confirmation.

Thanks for keeping us in the loop on these changes/designs.

Comment 7

[Julie Martin]

Here's what we say about crash reports currently, let me know if this operates differently in any way so I can update it:

Crash-Reporting Feature. Firefox has a crash-reporting feature that sends a report to Mozilla when Firefox crashes. Mozilla uses the information in the crash reports to diagnose and correct the problems in Firefox that caused the crash. Though this feature starts automatically after Firefox crashes, it does not send information to Mozilla until you explicitly authorize it to do so. By default, this feature sends a variety of Non-Personal Information to Mozilla, including the stack trace (a detailed description of which parts of the Firefox code were active at the time of the crash) and the type of computer you are using. Additional information is collected by the crash reporting feature. Which crash reporting feature is used and what additional information collected by Firefox depends on which version of Firefox you’re using. For pre-3.x versions of Firefox, please see the end of this privacy policy.

Firefox 3.0 to present.

    For the current versions of Firefox, “Firefox Crash Reporter” is Firefox’s crash reporting feature. With this feature, you have the option to include Personal Information (including your email address), Potentially Personal Information (including your IP address and the URL of the site you were visiting when Firefox crashed), and a comment. Firefox Crash Reporter also sends a list of all add-ons that you were using at the time of the crash, the time since (i) the last crash, (ii) the last install, and (iii) the start-up of the program. For Firefox 3.0.0 – 3.0.5, Firefox Crash Reporter also collects Potentially Personal Information to Mozilla in the form of a unique alphanumeric value to distinguish individual Firefox installs. This value is not assigned to users of Firefox 3.0.6 and subsequent versions. Mozilla only makes Non-Personal Information (i.e., generic information about your computer, the stack trace, and any comment given by the user) available in the public reports available online at http://crash-stats.mozilla.com/.

Comment 8

[Mike Beltzner [:beltzner, not reading bugmail]]

Julie: yup, that's all still correct. The OOPP reporter doesn't give the option to submit the URL or the email address (yet, I think there are plans to perhaps allow users to submit that extra information at some future date) but the language in comment 7 applies to this new crash reporter as well.

Comment 9

[Justin Dolske [:Dolske]]

Attachment: Patch v.1

Comment 10

[Justin Dolske [:Dolske]]

Comment on attachment 437736 [details] [diff] [review]
Patch v.1

(oops)

The one thing I didn't do here was make the icon and "The XXX plugin crashed" clickable. Since other clickable text in the UI is clearly marked (underlined), it seemed confusing.

Comment 11

[Justin Dolske [:Dolske]]

Attachment: Screenshot of patch v.1

Comment 12

[Justin Dolske [:Dolske]]

Also took the opportunity here to control the message display through CSS, instead of poking at the DOM style directly. I think that makes the code clearer.

Comment 13

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 437736 [details] [diff] [review]
Patch v.1

I think I'd still prefer if the hit area was larger, but not so much that I'd ui-r- this.

Comment 14

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 437736 [details] [diff] [review]
Patch v.1

>diff --git a/toolkit/mozapps/plugins/content/pluginProblemContent.css b/toolkit/mozapps/plugins/content/pluginProblemContent.css

>+.submitStatus[status="noReport"]   .msgNoCrashReport,
>+.submitStatus[status="please"]     .msgPleaseSubmit,
>+.submitStatus[status="noSubmit"]   .msgNotSubmitted,
>+.submitStatus[status="submitting"] .msgSubmitting,
>+.submitStatus[status="success"]    .msgSubmitted,
>+.submitStatus[status="failed"]     .msgSubmitFailed,
>+:-moz-handler-crashed .submitStatus:not([status="please"]) .msgReload {

Can you use:

.submitStatus[status]:not([status="please"]) .msgReload

instead, and/or add a comment? I had a hard time figuring out why the :-moz-handler-crashed was needed.

>diff --git a/toolkit/themes/pinstripe/mozapps/plugins/pluginProblem.css b/toolkit/themes/pinstripe/mozapps/plugins/pluginProblem.css

>+.submitStatus div {
>+    min-height: 19px; /* height of biggest line (with throbber) */
>+}

Is this just experimentally derived, or based on some other styling? If the former, have you tested to make sure it works with both themes? If the latter, can you refer to the specific relevant rules/images?

Comment 15

[u88484]

I think a string change or two is needed here.  "... plugin has crashed.  Crash report sent" would sound a lot better as " ... plugin has crashed and a crash report has (not) been sent."  

Also, reload the page to try what again?  At least append a please.

Comment 16

[Justin Dolske [:Dolske]]

(In reply to comment #14)

> >+.submitStatus div {
> >+    min-height: 19px; /* height of biggest line (with throbber) */
> >+}
> 
> Is this just experimentally derived, or based on some other styling? If the
> former, have you tested to make sure it works with both themes?

The former, I tested experimentally on all 3 platforms with DOMi and checked the results when this landed in bug 550293. (Which reminds me, I didn't delete the now-obsolete ".msgBottomLinks div" rule. Fixed)

(In reply to comment #15)
> I think a string change or two is needed here.

Nope. We're string frozen for Lorentz, so not going change anything now.

Comment 17

[Justin Dolske [:Dolske]]

Attachment: Patch v.2

Updated patch.

Comment 18

[Justin Dolske [:Dolske]]

Pushed http://hg.mozilla.org/mozilla-central/rev/79085c747589

Comment 19

[Alfred Kayser]

A nit:
  .submitStatus div
should be:
  .submitStatus>.msg

Comment 20

[Justin Dolske [:Dolske]]

Attachment: Patch v.2 (branch)

Comment 21

[Justin Dolske [:Dolske]]

Pushed http://hg.mozilla.org/releases/mozilla-1.9.2/rev/165d32c2aacf

(In reply to comment #19)
> A nit:

New bug (and patch ;), please.

Comment 22

[Julie Martin]

Re Comment 7:  let's leave the privacy policy as is for now and I can add specific delineations as to this crash reporter in the next rework of the FF PP.

Comment 23

[Mike Beltzner [:beltzner, not reading bugmail]]

Justin: for the sake of documentation, what happens when someone reloads the page after submitting a crash report but before the throbber stops throbbing?

Comment 24

[Justin Dolske [:Dolske]]

Reloading the page does not affect submission. As soon as you click "submit", the crash reporter starts submission (which is handled by chrome), and the UI basically just listens for progress updates to change state.

Comment 25

[Al Billings [:abillings - ex-MoCo]]

Verified that this change has gone into 1.9.2 and is in the last nightly before release builds began: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.4pre) Gecko/20100413 Namoroka/3.6.4pre