Closed Bug 813128 Opened 9 years ago Closed 9 years ago
Final text for "Crash Reports" information page
246 bytes, text/html
I'm going to land bug 801938 with a placeholder sting, but we need to get a final string in there ASAP.
This is part of bug 801938, which is a blocker.
blocking-basecamp: --- → ?
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.
This text is not final - update coming shortly
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.
(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.
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?
(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.
Cc'ing lco in case she's thought about how links in modal dialogs might work, if they should even be there at all.
Attachment #683689 - Flags: review?(kaze)
Comment on attachment 683689 [details] Link to https://github.com/mozilla-b2g/gaia/pull/6536 https://github.com/mozilla-b2g/gaia/commit/456ab87f54380b86125aaf1173f3482892f5aaa5
Attachment #683689 - Flags: review?(kaze) → review+
Can we close this now or do you want to implement the link behavior in this bug as well (comment 10)?
(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
Closed: 9 years ago
Resolution: --- → FIXED
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.