Final text for "Crash Reports" information page

RESOLVED FIXED

Status

P1
normal
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: Margaret, Assigned: Margaret)

Tracking

({l12y})

unspecified
x86
Mac OS X
Dependency tree / graph

Firefox Tracking Flags

(blocking-basecamp:+)

Details

Attachments

(1 attachment)

(Assignee)

Description

6 years ago
I'm going to land bug 801938 with a placeholder sting, but we need to get a final string in there ASAP.
(Assignee)

Comment 1

6 years ago
This is part of bug 801938, which is a blocker.
blocking-basecamp: --- → ?

Comment 2

6 years ago
Here's our text, which has been looked at by Jishnu too.

* * * * *

A crash report contains some details about the crash and your device, as well as a snapshot of the state of your device when it crashed. This can include things like:

* open pages and apps
* text typed into forms
* recent browsing history
* contents of open messages
* geolocation used by an open app

We use crash reports to fix problems and improve $PRODUCTNAME.

Comment 3

6 years ago
This text is not final - update coming shortly

Comment 4

6 years ago
A crash report contains some details about the crash and your device, as well as a snapshot of the state of your device when it crashed. 

This may include things like open pages and apps, text typed into forms and the content of open messages, recent browsing history, or geolocation used by an open app.

We use crash reports to try to fix problems and improve our products. We handle your information as we describe in our [privacy policy]. [https://www.mozilla.org/privacy]
Keywords: l12y
FYI, due to the short turnaround between the landing of bug 801938 and (hopefully) this one, I don't think we'll need to change the identifiers of the strings.  I didn't extract the placeholder strings into Mercurial, so the localizers haven't seen them yet.
(Assignee)

Comment 6

6 years ago
(In reply to Staś Małolepszy :stas from comment #5)
> FYI, due to the short turnaround between the landing of bug 801938 and
> (hopefully) this one, I don't think we'll need to change the identifiers of
> the strings.  I didn't extract the placeholder strings into Mercurial, so
> the localizers haven't seen them yet.

I'll work on landing this today. However, because there are 3 different paragraphs (and one that includes a link), I'll need to change the identifiers to account for that.

Comment 7

6 years ago
Thanks for this - what's the behavior with the link? If we take someone out of the crash reporting flow, will the be able to get back?
(Assignee)

Comment 8

6 years ago
(In reply to Jishnu Menon from comment #7)
> Thanks for this - what's the behavior with the link? If we take someone out
> of the crash reporting flow, will the be able to get back?

So, I was actually just wondering about this myself. In page that appears in the settings app, this link just opens in the browser, which makes sense. However, when I added a link to the page that appears in the crash dialog, it opened a web view that took up the whole screen and there was no way to get back.

How critical is the link in this case? I'm afraid it will require more code changes to get this link to work properly, including figuring out the UX for opening a link from a modal dialog.

To land the strings ASAP, I could still land this without making that part of text into a link (in the crash dialog part only), and then we can follow up with making it into a link later.
(Assignee)

Comment 9

6 years ago
Cc'ing lco in case she's thought about how links in modal dialogs might work, if they should even be there at all.
(Assignee)

Comment 10

6 years ago
Created attachment 683689 [details]
Link to https://github.com/mozilla-b2g/gaia/pull/6536

I didn't make the "privacy policy" link in the crash dialog into an actual link for now because I haven't sorted out the behavior of what a link in a modal dialog should do. However, this will get the strings landed, which is the important part!
Attachment #683689 - Flags: review?(kaze)
Can we close this now or do you want to implement the link behavior in this bug as well (comment 10)?
blocking-basecamp: ? → +
Priority: -- → P1
(Assignee)

Comment 13

6 years ago
(In reply to Staś Małolepszy :stas from comment #12)
> Can we close this now or do you want to implement the link behavior in this
> bug as well (comment 10)?

Let's just close this bug. We can file a follow-up bug for the link, since that's not the blocking issue. I still need to hear back about how we would handle the UX for that link if we do implement it.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Comment 14

6 years ago
(In reply to Margaret Leibovic [:margaret] from comment #13)
> (In reply to Staś Małolepszy :stas from comment #12)
> > Can we close this now or do you want to implement the link behavior in this
> > bug as well (comment 10)?
> 
> Let's just close this bug. We can file a follow-up bug for the link, since
> that's not the blocking issue. I still need to hear back about how we would
> handle the UX for that link if we do implement it.

Sorry, Just got back. I didn't anticipate having a link, honestly. Jishnu, how important is it to have?

The question is really about system vs app modal dialog behavior. What happens when the user hits the home button when a crash dialog comes up, for example. Do we allow the user to close the crash dialog, or do we disable the home button? (I vaguely remember discussing this with Josh, but I don't know if we ever came to a good conclusion.) In the same way, if we send the user out to the browser, is this the same as dismissing the crash report, or does the crash report persist on the home screen for the user to go back to?

If we are being consistent with the definition of a system modal dialog, we wouldn't let the user exit without making a choice. Following this line of thought, the crash report screen would persist on the home screen even if the user taps the home button or goes to view our privacy policy on a webpage.

The alternative is to say that the crash dialog gets dismissed (with some default choice) when the user hits the home button or the privacy policy link. I don't link this behavior because the user hasn't really made a choice, it was just sort of made for him. 

Does my first suggestion (persisting the crash report on the home screen) sound good to people / is it feasible without changing too much behavior?
(Assignee)

Updated

6 years ago
Blocks: 815451
(Assignee)

Comment 15

6 years ago
I filed bug 815451 as a follow-up about adding the link.
You need to log in before you can comment on or make changes to this bug.