As described in bug 1241459 comment 11, and bug 1241459 comment 14. We added the "automatically submit backlogged crash reports" preference in bug 1287178.

This is follow-up work for bug 1241459 which blocked e10s-multi, so I guess this should block e10s-multi too.

Simplest thing I could think of is to just append it to the list of options already in about:tabcrashed. I'm cribbing the string that we use in about:preferences (Data Choices). Does this work for you, phlsa?

Hey Mike, looks good! Just a few comments: - The placement of the checkbox (inside the gray box) implies that the choices made in that gray box will also be used the next time. I assume that's not true, so it would probably be better to place it right underneath the gray box, above the buttons. - The string strikes me as a little odd. The user has more context in this scenario than he has in preferences, so we could use something like »Automatically submit crash reports in the future«, echoing the string used in the topmost checkbox on that same screen.

(In reply to Philipp Sackl [:phlsa] (Firefox UX) please use needinfo from comment #4) > Hey Mike, looks good! Just a few comments: > > - The placement of the checkbox (inside the gray box) implies that the > choices made in that gray box will also be used the next time. I assume > that's not true, so it would probably be better to place it right underneath > the gray box, above the buttons. Sure, I'll mock that up and we'll take a look. > - The string strikes me as a little odd. The user has more context in this > scenario than he has in preferences, so we could use something like > »Automatically submit crash reports in the future«, echoing the string used > in the topmost checkbox on that same screen. My one worry here is that this gives the user the impression that they'll never see about:tabcrashed again, which might not be the case if their selected tab crashes. Do you think my concern is legitimate? Should I work with mheubusch to get a clear string here?

(In reply to Mike Conley (:mconley) - (high latency on reviews and needinfos) from comment #5) > (In reply to Philipp Sackl [:phlsa] (Firefox UX) please use needinfo from > comment #4) > > Hey Mike, looks good! Just a few comments: > > > > - The placement of the checkbox (inside the gray box) implies that the > > choices made in that gray box will also be used the next time. I assume > > that's not true, so it would probably be better to place it right underneath > > the gray box, above the buttons. > > Sure, I'll mock that up and we'll take a look. Great, thanks! > > - The string strikes me as a little odd. The user has more context in this > > scenario than he has in preferences, so we could use something like > > »Automatically submit crash reports in the future«, echoing the string used > > in the topmost checkbox on that same screen. > > My one worry here is that this gives the user the impression that they'll > never see about:tabcrashed again, which might not be the case if their > selected tab crashes. Do you think my concern is legitimate? Should I work > with mheubusch to get a clear string here? Hm, that's hard to say... let's ask Michelle :)

Something more like this? I'm not proposing this string exactly, but is the placement right?

ni? for placement in comment 7.

Wonderful! :)

Hey bsmedberg, One of the changes that phlsa and mheubusch are suggesting is that we remove the email field in the about:tabcrashed page to reduce the amount of visual noise it adds. Is the email field really useful? Do we use it to contact users that have submitted reports? I recall https://wiki.mozilla.org/PostCrash went nowhere, but is there precedent for reaching out to crash report submitters for crashes that we have a harder time getting good information on?

Uploaded three screens reflecting different states of messaging. Note that for More Than One Tab . . . only the Restore All Tabs button should be the sole primary button.

We have used the email field in the past, although rarely. There were a couple of notable success stories from it. For a long time it wasn't useful because we didn't record the locale, so we were emailing in English to people in many different languages. That is now fixed, but the circumstances where emailing users is a good option are very small. Right now ~1% of our users submit a real email address. One of the future promises of the SHIELD/self-support mechanism is that we'd be able to show in-product prompts to users who experienced certain crashes, either to get more information or prompt them to take action (such as upgrading or uninstalling buggy software). That is not yet available. So the tradeoff of the email address is not 100% obvious to me.

perhaps we could hide it for the general case and if we're looking for a user who experiences a crash ship a system add-on that shows it selectively based on the signature (or other characteristics) of the crash.

(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #16) > perhaps we could hide it for the general case and if we're looking for a > user who experiences a crash ship a system add-on that shows it selectively > based on the signature (or other characteristics) of the crash. I like the idea, but I _think) that means we need to symbolicate the crash dump before we can determine if the signature is one we want to show the e-mail input for. What I'll do for now is hide it behind a pref.

I've started to implement Michelle's wireframes. Here's a screenshot of where I've gotten so far.

Heh, whoops.

Comment on attachment 8805672 [details] Applied changes Hey phlsa, I've taken mheubusch's wireframes and this is where I've gotten to. Before I continue, am I headed down the right track here? In particular: 1) The grey box has 14px of padding. The wireframe had the text all left-aligned, which means that the box border necessarily "leaks" to the left into the margins. Is this alright? 2) The long string, "Update preferences to automatically...", breaks in the middle of a parenthetical. Is that okay?

Just to confirm, the string at the header is to be "Ooh. Your tab just crashed." and not "Oh. Your tab just crashed.", correct? Also, I hope it's alright - I've switched one string from "Submit a crash report for the tab you are viewing" to "Send a crash report for the tab you are viewing", to be more consistent with the other places we've been changing recently. Is this okay?

Looks good! I highlighted two issues in the attachment. The one about the margin is (I think) what you also mentioned. It's not big deal, but if we can make it even it would be better. For the last checkbox, I think the most important part is that the second line has the same indentation as the first line. If we can get the parenthesis to be all in the second line that would also be good, but I'm assuming that this would mess with localization?

(In reply to Mike Conley (:mconley) - (digging out of review / needinfo backlog) from comment #21) > Just to confirm, the string at the header is to be "Ooh. Your tab just > crashed." and not "Oh. Your tab just crashed.", correct? > > Also, I hope it's alright - I've switched one string from "Submit a crash > report for the tab you are viewing" to "Send a crash report for the tab you > are viewing", to be more consistent with the other places we've been > changing recently. Is this okay? Let's go with "Gah. Your tab just crashed." Also, confirming your change to Send a crash report . . .

Comment to add for localizers: "Gah is an English slang word used to express surprise or frustration (or both at the same time). We are using it to communicate in an informal way that it is both frustrating that your tab crashed and a surprise that we didn't want to happen. If you have a similar word or short phrase that is not profane or vulgar, use it if. If not, feel free to skip the word in your translation."

Comment on attachment 8805672 [details] Applied changes Forgot to remove this flag... See my previous comment. We should at least fix the line break. The margin isn't as critical.

Comment on attachment 8809807 [details] Bug 1309316 - Expose preference for auto-submitting backlogged crash reports to about:tabcrashed. https://reviewboard.mozilla.org/r/92320/#review92354 A note about these patches, felipe: 1) In order to get the wrapping on the text correct for the autosubmission checkbox, I had to stop using the hacky pseudoelement on the <label> and expose the real checkbox instead. I'm waiting on bug 418833 to land so that the styles I'm applying will work properly. Until it does (and I uplift it), the checkboxes are going to look a little weird in about:tabcrashed. 2) If you want to manually test this, you'll need to modify the `./mach run` command so that it doesn't disable the crash reporter by default. The patch at https://pastebin.mozilla.org/8927208 will do that. Coupled with Tab Crasher (or Crash Me Now Simple at https://addons.mozilla.org/en-US/firefox/addon/crash-me-now-simple/ ) will make it possible to test this.

Comment on attachment 8809807 [details] Bug 1309316 - Expose preference for auto-submitting backlogged crash reports to about:tabcrashed. https://reviewboard.mozilla.org/r/92322/#review92368

Comment on attachment 8809808 [details] Bug 1309316 - Move about:tabcrashed tests into their own directory. https://reviewboard.mozilla.org/r/92324/#review92372 yay, less tests in the general folder \o/

Comment on attachment 8809809 [details] Bug 1309316 - Add tests for autosubmission request in about:tabcrashed. https://reviewboard.mozilla.org/r/92326/#review92374

Comment on attachment 8809810 [details] Bug 1309316 - Hide email field in about:tabcrashed by default. https://reviewboard.mozilla.org/r/92328/#review92376

Pushed by mconley@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/25412fab8aa5 Expose preference for auto-submitting backlogged crash reports to about:tabcrashed. r=Felipe https://hg.mozilla.org/integration/autoland/rev/3b3082d32c0d Move about:tabcrashed tests into their own directory. r=Felipe https://hg.mozilla.org/integration/autoland/rev/a80600db579d Add tests for autosubmission request in about:tabcrashed. r=Felipe https://hg.mozilla.org/integration/autoland/rev/44af2c3d71ea Hide email field in about:tabcrashed by default. r=Felipe

MozReview-Commit-ID: 189oSFKHmxU

Pushed by archaeopteryx@coole-files.de: https://hg.mozilla.org/integration/autoland/rev/e87192b94a97 Follow-up: disable test when crashreporter is not available. r=bustage-fix

https://hg.mozilla.org/mozilla-central/rev/25412fab8aa5 https://hg.mozilla.org/mozilla-central/rev/3b3082d32c0d https://hg.mozilla.org/mozilla-central/rev/a80600db579d https://hg.mozilla.org/mozilla-central/rev/44af2c3d71ea https://hg.mozilla.org/mozilla-central/rev/e87192b94a97

Is it just me or the last checkbox and section title seem disconnected? https://bug1309316.bmoattachments.org/attachment.cgi?id=8805672 How is "Request background tabs" related to the preference to automatically send queued crash reports?

(In reply to Francesco Lodolo [:flod] from comment #40) > Is it just me or the last checkbox and section title seem disconnected? > https://bug1309316.bmoattachments.org/attachment.cgi?id=8805672 > > How is "Request background tabs" related to the preference to automatically > send queued crash reports? Michelle, any suggestion about this?

(In reply to Francesco Lodolo [:flod] from comment #40) > Is it just me or the last checkbox and section title seem disconnected? > https://bug1309316.bmoattachments.org/attachment.cgi?id=8805672 > > How is "Request background tabs" related to the preference to automatically > send queued crash reports? Same question for Mike, since I've seen doubts from localizers too.

Following up per my conversation with mconley: Headline should be: Gah. This tab has crashed. Last subhead should start with "Report" not request.

To be clear, see this latest attachment for the up-to-date state of about:tabcrashed. The title is correct as per mheubusch's spec, but her last point remains - I accidentally substituted the word "Request" for "Report". flod - what are our options here? Can I ninja-edit this so close to Beta uplift, or is that going to give our localizers a hard time?

(In reply to Mike Conley (:mconley) from comment #44) > flod - what are our options here? Can I ninja-edit this so close to Beta > uplift, or is that going to give our localizers a hard time? Sadly it's going to give them a hard-time, but given how confusing the sentence is, I thing we should try to land the correct string (with a new ID) as soon as possible, and hope they manage to translate it before Jan 24. If you can get a patch and poke release-drivers/sheriffs to get it landed in aurora before the week-end, I can send the email out.

How "Update preferences to automatically submit backlogged crash reports (and get fewer messages like this from us in the future)" relates to reporting background tabs (and what actually gets reported)?

ni'ing mheubusch, who is working on a localization note.

(In reply to Stefan Plewako [:stef] from comment #46) > How "Update preferences to automatically submit backlogged crash reports > (and get fewer messages like this from us in the future)" relates to > reporting background tabs (and what actually gets reported)? Hello Stefan, when you update your preferences to submit backlogged crash reports you will submit the background tabs from the current session and future sessions. Maybe a clearer way to say this in English is: Update preferences to automatically submit backlogged crash reports, including the background tabs from this session and future sessions. @flod - would this advice help other localizers? If so is there a way to share?

Setting a needinfo for flod for comment 48.

(In reply to mheubusch from comment #48) > when you update your preferences to submit backlogged crash reports you > will submit the background tabs from the current session and future > sessions. Maybe a clearer way to say this in English is: Update preferences > to automatically submit backlogged crash reports, including the background > tabs from this session and future sessions. > > @flod - would this advice help other localizers? If so is there a way to > share? I think this string would be much clearer, but I'm not sure if this should be advice to send to localizers as much as a change to do in the current UI for English (letting it ride the trains, though).

(In reply to mheubusch from comment #48) > when you update your preferences to submit backlogged crash reports you > will submit the background tabs from the current session and future > sessions. Maybe a clearer way to say this in English is: Update preferences > to automatically submit backlogged crash reports, including the background > tabs from this session and future sessions. I'm quite lost here, reading current checkbox description label I thought it was about automatic tab crash reporting. Assuming background tabs are other open in UI tabs it doesn't make clear to me what will actually be submitted? As background tabs are probably healthy pages, will URL or title or prefilled passwords or cookies be sent to?

(In reply to Stefan Plewako [:stef] from comment #51) > Update preferences to automatically submit backlogged crash reports, including the background > tabs from this session and future sessions. Maybe "… including *reports* for the background tabs from this session and future sessions" to avoid further confusion.

While trying to test this with https://addons.mozilla.org/pl/firefox/addon/crash-me-now-simple/ and crashing web content process, I find this even more confusing. It doesn't specify to whom the data will be sent and the whole thing could be implemented as regular page - are we sure that users shouldn't care if what they see comes from the web or the app?

ni'ing mheubusch for comment 53.

Actually, on re-reading this, I'm not entirely sure what comment 53 means. (In reply to Stefan Plewako [:stef] from comment #53) > While trying to test this with > https://addons.mozilla.org/pl/firefox/addon/crash-me-now-simple/ and > crashing web content process, I find this even more confusing. It doesn't > specify to whom the data will be sent and the whole thing could be > implemented as regular page - are we sure that users shouldn't care if what > they see comes from the web or the app? I don't understand "the whole thing could be implemented as regular page" and "are we sure that users shouldn't care if what they see comes from the web or the app"? Are you saying that you find it strange that the message is coming from the area where we normally display web content? Is that what you mean when you talk about the difference between what users see coming "from the web or the app"?

(In reply to Mike Conley (:mconley) - Getting through review / needinfo backlog from comment #55) > Actually, on re-reading this, I'm not entirely sure what comment 53 means. > > (In reply to Stefan Plewako [:stef] from comment #53) > > While trying to test this with > > https://addons.mozilla.org/pl/firefox/addon/crash-me-now-simple/ and > > crashing web content process, I find this even more confusing. It doesn't > > specify to whom the data will be sent and the whole thing could be > > implemented as regular page - are we sure that users shouldn't care if what > > they see comes from the web or the app? > > I don't understand "the whole thing could be implemented as regular page" > and "are we sure that users shouldn't care if what they see comes from the > web or the app"? > > Are you saying that you find it strange that the message is coming from the > area where we normally display web content? Is that what you mean when you > talk about the difference between what users see coming "from the web or the > app"? Yes, that too I think but I don't exactly understand 'the difference between what users see coming "from the web or the app"'.

(In reply to Stefan Plewako [:stef] from comment #56) > Yes, that too I think but I don't exactly understand That's where we're confused. You said 'the difference between what users see coming "from the web or the app"' here in comment 53. We're not 100% sure what it means. Can you please try rephrasing it?

This https://trash.splewako.com/bug.1309316.html is confusing even if not doing anything really - even if it would be real Firefox UI it would be hardly recognizable as such. This makes one wonder what things like "help us" (help who) and "Send" (send where) really mean - they are ambiguous and with headers like "Report background tabs" makes users question if this is somehow malicious and ends with tab close (tested).

(In reply to Stefan Plewako [:stef] from comment #58) > This https://trash.splewako.com/bug.1309316.html is confusing even if not > doing anything really - even if it would be real Firefox UI it would be > hardly recognizable as such. > > This makes one wonder what things like "help us" (help who) and "Send" (send > where) really mean - they are ambiguous and with headers like "Report > background tabs" makes users question if this is somehow malicious and ends > with tab close (tested). So, just so we're clear, what you're expressing is concern about the UX and user-interpretation of the page, and not a problem creating the actual translation strings, correct? If so, here's what I'm extracting from comment 58: stef is concerned that the base about:tabcrashed doesn't look like a "real" error page, and this makes the strings like "help us" and "send" feel a bit dangerous, since the user might not trust the page. Is that correct stef?

(In reply to Mike Conley (:mconley) - Getting through review / needinfo backlog from comment #59) > So, just so we're clear, what you're expressing is concern about the UX and > user-interpretation of the page, and not a problem creating the actual > translation strings, correct? No, I'm expressing concern about the UX and user-interpretation of the page and the problem with creating the actual translation for the "Report background tabs" string (because of disconnection with description and needed information). > stef is concerned that the base about:tabcrashed doesn't look like a "real" > error page, and this makes the strings like "help us" and "send" feel a bit > dangerous, since the user might not trust the page. > > Is that correct stef? Yes (for the concern about UX part)

Hey flod, care to weigh in here? I'm not sure how to proceed.

There seem to be two issues, if I read Stefan's comments correctly. One is about the user experience. The error page is displayed in-content, the user might think it's a web page instead of chrome content, i.e. a legitimate dialog from Firefox that can be trusted with their email. Think for example of ads faking Flash Windows updates and trying to scam people into clicking. I personally don't think it's an issue, but I assume it's something UX should at least think about, if they didn't already. One is about the disconnection between the title "Report background tabs", and the description "Update preferences to automatically submit backlogged crash reports (and get fewer messages like this from us in the future)". The link between "background tabs" and "backlogged crash reports" is far from intuitive. That's discussed from comment 48 to 50. It's also unclear what "background tabs" means: all background tabs? Only if they crashed? My take would be to update the description to something like: "Update preferences to automatically submit crash reports, including reports for crashed background tabs from this session and future sessions." No technical jargon (backlogged), clear indication that only crashed tabs will be sent (assuming that's the case). But that's more food for thought for Michelle than an actionable suggestion.

Thanks flod. Another question - given this confusion, are we unlikely to get the pl version of about:tabcrashed in Firefox localized? Like, is this confusion actively preventing us from shipping a localized Firefox? And over to mheubusch on flod's string suggestion. What do you think of: "Update preferences to automatically submit crash reports, including reports for crashed background tabs from this session and future sessions"?

Polish is currently missing that string, but I don't believe it will be missing for long, especially if we agree on a better string to land in m-c (it should happen before tomorrow, given the end of the cycle, to be exposed to all locales in aurora). Unfortunately we can't do much for 52 at this point.

(In reply to Mike Conley (:mconley) - PTO on Jan 20th from comment #63) > Thanks flod. Another question - given this confusion, are we unlikely to get > the pl version of about:tabcrashed in Firefox localized? Like, is this > confusion actively preventing us from shipping a localized Firefox? > > And over to mheubusch on flod's string suggestion. What do you think of: > > "Update preferences to automatically submit crash reports, including reports > for crashed background tabs from this session and future sessions"? I agree - this is better than my similar suggestion in 48. Thank you, Flod.

(In reply to Mike Conley (:mconley) - PTO on Jan 20th from comment #63) > Thanks flod. Another question - given this confusion, are we unlikely to get > the pl version of about:tabcrashed in Firefox localized? Like, is this > confusion actively preventing us from shipping a localized Firefox? Flod is right. I just wanted to change it only once on aurora. No problem here.