I have no clue about stories (and also think that the concept itself doesn't really fit well in a 1:1 relationship to bugs) but we definitely are getting crash reports from metro already right now - see the MetroFirefox product on crash-stats.

(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #1) > I have no clue about stories (and also think that the concept itself doesn't > really fit well in a 1:1 relationship to bugs) but we definitely are getting "Story -" == "[Tracking]" > crash reports from metro already right now - see the MetroFirefox product on > crash-stats. Reporting is currently controlled by the front end - http://mxr.mozilla.org/mozilla-central/source/browser/metro/base/content/browser-ui.js#217 So we miss startup crashes. Bug 797023 is all about moving submittal down into nsAppRunner so we get everything.

(In reply to Jim Mathies [:jimm] from comment #2)As > So we miss startup crashes. Bug 797023 is all about moving submittal down > into nsAppRunner so we get everything. As long as we have proper UI and per-crash opt-in to sending, that sounds fine.

(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #3) > (In reply to Jim Mathies [:jimm] from comment #2)As > > So we miss startup crashes. Bug 797023 is all about moving submittal down > > into nsAppRunner so we get everything. > > As long as we have proper UI and per-crash opt-in to sending, that sounds > fine. We won't have per-crash opt-in, just a master reporting pref (bug 844619). There's no way to inject crash reporter UI into the metro environment, so reporting is "headless".

(In reply to Jim Mathies [:jimm] from comment #4) > We won't have per-crash opt-in, just a master reporting pref (bug 844619). > There's no way to inject crash reporter UI into the metro environment, so > reporting is "headless". Sounds like a major privacy issue, and as well a major issue with getting incredibly useful data like comments and email addresses. There are reasons why the crash reporting UX is as it is on desktop and Android right now, and why we need explicit prompts to send every crash and additionally explicit opt-in when sending URLs with those. We have tried a slightly different way for Firefox OS, but even there we require explicit opt-in before sending the first crash report. Otherwise this would be a huge privacy violation and therefore undermine what we say in the Mozilla Manifesto.

(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #5) > (In reply to Jim Mathies [:jimm] from comment #4) > > We won't have per-crash opt-in, just a master reporting pref (bug 844619). > > There's no way to inject crash reporter UI into the metro environment, so > > reporting is "headless". > > Sounds like a major privacy issue, and as well a major issue with getting > incredibly useful data like comments and email addresses. There are reasons > why the crash reporting UX is as it is on desktop and Android right now, and > why we need explicit prompts to send every crash and additionally explicit > opt-in when sending URLs with those. > We have tried a slightly different way for Firefox OS, but even there we > require explicit opt-in before sending the first crash report. Otherwise > this would be a huge privacy violation and therefore undermine what we say > in the Mozilla Manifesto. We could solve this by initially disabling. However, fresh installs that crash on startup would never submit. Those are the reports we really want to see. If we can't get the browser front end loaded, we can't prompt the user, hence no reporting at all from those installs. Aas suggested moving initial opt in into the installer? Would this help alleviate your privacy concerns?

We would also have to come up with some way of dealing with upgrades, since we package with Firefox proper. Maybe we could read something from crash reporter registry related keys for Firefox and translate that over to metrofx.

In the installer would be a way but I fear that it would be an annoyance for people there and anything we add to the installer might harm conversion rates. We'll also need to go through the privacy team anyhow if we are doing things differently than on current desktop or Android builds. In Firefox OS, there was also concern that adding this to the First Run Experience screen would be bad, so we ended up doing a prompt either on the first crash if it's a content process or on restart if it's a Gecko crash. If there's no way of doing UI from the crash reporter process (I wonder why it can't but I don't claim to understand Metro) then maybe something similar to the FxOS experience can be done here as well.

(In reply to Jim Mathies [:jimm] from comment #7) > We would also have to come up with some way of dealing with upgrades, since > we package with Firefox proper. Maybe we could read something from crash > reporter registry related keys for Firefox and translate that over to > metrofx. Oh, that I don't think that's possible, because any Firefox desktop setting is made for a prompt-for-each-crash UI, and if we have to break that, which is unfortunately as it makes reports way less actionable to us (no comments, no emails, possibly no URLs), then we cannot take any prefs made for that UI into account.

(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #8) > In the installer would be a way but I fear that it would be an annoyance for > people there and anything we add to the installer might harm conversion > rates. We'll also need to go through the privacy team anyhow if we are doing > things differently than on current desktop or Android builds. In Firefox OS, > there was also concern that adding this to the First Run Experience screen > would be bad, so we ended up doing a prompt either on the first crash if > it's a content process or on restart if it's a Gecko crash. If there's no > way of doing UI from the crash reporter process (I wonder why it can't but I > don't claim to understand Metro) then maybe something similar to the FxOS > experience can be done here as well. Unfortunately crashreporter.exe can't integrate with the metro ui, only the browser process is registered to do that. The only way I can think of would be to shunt out on startup and add a bunch of custom metro interface / direct3d code into some sort of a "browser first run splash" screen. This would be no small task and would also be subject to first run crash problems. It would be far simpler to do something when the user installs. If we can't rely on desktop crash reporter settings for updates, I'd suggest the following: 1) an in browser Options pref that defaults to off for update users. We can prompt users from our first run screen to get more of these turned on. 2) an installer checkbox option for fresh or pave-over installs that defaults to checked. with this setup we lose startup crash issue reporting for all users who already have firefox installed and can't get metrofx running. But I think that pretty quickly we'll be able to fix most serious startup problems, so this will become less of an issue over time. For users who file bugs, we can ask them to do a pave over install and opt-in to crash reporting. Also, on mc builds, I would like to turn crash reporting on by default, no prompting, with only the Options pref for control. Is this ok? I believe we already have opt-out as the default on nightlies. Kairo, is there someone from privacy we should cc into the discussion?

Maybe we can mod the crash reporter to set it's parent to the metro process' CoreWindow's HWND so it shows up on top?

Sorry I meant owner not parent.

(In reply to Brian R. Bondy [:bbondy] from comment #11) > Maybe we can mod the crash reporter to set it's parent to the metro process' > CoreWindow's HWND so it shows up on top? That would be tricky. The browser normally exits independent from crashreporter.exe. So we would have to hold it around. I'm not sure how the winrt backend would react to that since we would not be processing events, or we would have to change our widget backend to allow it to do so. Alternatively I guess we could try to attach it to explorer's hwnd. :0 Not sure what that would do. Plus the ux is totally desktop oriented vs tablet/touch. We could probably make it work, but it would be ugly.

Fixing point value to align with closest fibonacci number

cc'ing a couple privacy folks in. We're trying to decide how to best handling getting the user's approval for crash reporting in metrofx.

Ah, good, you CCed Tom, he worked with us on Firefox OS crash reporting from a privacy POV.

If this is done via the installer then new profiles for the current user and all profiles for secondary users won't see this option. It would be better to find a different way to accomplish this.

(In reply to Robert Strong [:rstrong] (do not email) from comment #17) > If this is done via the installer then new profiles for the current user and > all profiles for secondary users won't see this option. It would be better > to find a different way to accomplish this. Reporting for new users can default to off. We can push these users to opt-in through the first run screen. The installer option would only apply to the user who installed firefox - basically an HKEY_CURRENT_USER flag in the reg.

OK though I think a first run screen for everyone should be sufficient with it defaulting to on until that point. If you go this route please run the new installer and stub installer UI through UX (the UI is already getting crowded).

(In reply to Robert Strong [:rstrong] (do not email) from comment #19) > OK though I think a first run screen for everyone should be sufficient with > it defaulting to on until that point. If you go this route please run the > new installer and stub installer UI through UX (the UI is already getting > crowded). First run is preferred, I'd rather just rely on that. What the installer option does is solve the problem of getting the user's consent before first run so we can catch and report startup crashes. We could just default reporting to on before first run is displayed. Then we wouldn't need anything in the installer.

Sorry, as much as I love to have the data (it's what I'm working with all day in the end), we cannot default to on before any user interaction for privacy reasons, I fear. But let's wait for what Tom has to say.

Can't we gather crashes and not submit them until the user opts in? How about we just ask in Firefox UI after our first successful crash recovery if we can send any reports that have accumulated. If the user says OK then we send off what we have and in the future submit them without intervention.

A final note. Because we're headless, we're not collecting email addresses or any notes the user might add to the report. I don't know how much that email field in the desktop crash reporter plays into the discussion of how much agreement we need from users, but it is different in Metro and that's worth calling out.

(In reply to Asa Dotzler [:asa] from comment #22) > Can't we gather crashes and not submit them until the user opts in? How > about we just ask in Firefox UI after our first successful crash recovery if > we can send any reports that have accumulated. If the user says OK then we > send off what we have and in the future submit them without intervention. Headless currently supports storing one crash to submit. We could augment that if need be. Of course, if the user can't get to the start screen, it doesn't make any difference how many crash reports you save.

(In reply to Jim Mathies [:jimm] from comment #24) > (In reply to Asa Dotzler [:asa] from comment #22) > > Can't we gather crashes and not submit them until the user opts in? How > > about we just ask in Firefox UI after our first successful crash recovery if > > we can send any reports that have accumulated. If the user says OK then we > > send off what we have and in the future submit them without intervention. > > Headless currently supports storing one crash to submit. We could augment > that if need be. Of course, if the user can't get to the start screen, it > doesn't make any difference how many crash reports you save. Let's store the one and ask the user to submit it on successful session restore, perhaps with a Message Dialog. As for missing start-up crashes, that will only be for people who have a permanent startup crash as their first crash, something I hope is rare. Everyone else will have, hopefully, already had a crash somewhere else and agreed to submit reports at some previous time. Their start up crashes will go right through.

(In reply to Asa Dotzler [:asa] from comment #25) > (In reply to Jim Mathies [:jimm] from comment #24) > > (In reply to Asa Dotzler [:asa] from comment #22) > > > Can't we gather crashes and not submit them until the user opts in? How > > > about we just ask in Firefox UI after our first successful crash recovery if > > > we can send any reports that have accumulated. If the user says OK then we > > > send off what we have and in the future submit them without intervention. > > > > Headless currently supports storing one crash to submit. We could augment > > that if need be. Of course, if the user can't get to the start screen, it > > doesn't make any difference how many crash reports you save. > > Let's store the one and ask the user to submit it on successful session > restore, perhaps with a Message Dialog. That's what we currently have (about:crash comes up) but we currently don't ask. > As for missing start-up crashes, that will only be for people who have a > permanent startup crash as their first crash, something I hope is rare. > Everyone else will have, hopefully, already had a crash somewhere else and > agreed to submit reports at some previous time. Their start up crashes will > go right through. Ok. However we have quite a few "crashes on startup" bugs already, which is what I was trying to fix in bug 797023.

We'll need a new bug on asking the user to submit.

Asa, for one thing, the team really, really should look at what we are doing with crash reporting in Firefox OS. I think a lot of that could be translated to Metro - even though this is just a browser and not an OS. That said, the emails and URLs are just icing on the cake privacy-wise, as the minidump we are sending, which is is core of the crash report, includes a section of the users' memory, and that can contain everything from passwords to credit card numbers and whatnot. The email and URLs information is incredibly useful to us when investigating crashes, so if we don't have that, we have less chance of improving stability, but it's info that people are intentionally volunteering via prompts anyhow.

"from the discussion in bug 831972, it's clear our normal submit method will have to be an about page where the user approves every submit." I'd rather we have a one-time opt in that's remembered. The flow I think we want is something like this: 1) Firefox crashes 2) Firefox automatically restarts and restores the session 3) User sees a Windows Message Dialog or similar alert letting her know that Firefox crashed, and that we'd appreciate her submitting crash reports. The message dialog has buttons for "submit crash reports" and "don't submit this report". 4) If the user picks "submit crash reports" we submit the report we've got and we set the "submit future reports silently" bit on the profile so the user never sees the prompt again. 5) If the user picks "don't submit this report" then we throw away that report the next time the user crashes, we go back to step 2).

I'll repeat once again: Please look at what we are doing for FxOS, please? For the record, that is somewhat similar to what Asa is proposing.

(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #30) > I'll repeat once again: Please look at what we are doing for FxOS, please? > > For the record, that is somewhat similar to what Asa is proposing. Got a link to documentation on what Firefox OS is doing? I looked around the wiki and wasn't able to find anything.

(In reply to Asa Dotzler [:asa] from comment #31) > Got a link to documentation on what Firefox OS is doing? I looked around > the wiki and wasn't able to find anything. The UI spec at http://people.mozilla.com/~lco/Crash_Reporting_B2G/R1_Crash%20Reports%20v1.pdf I think should explain most of it.

Thanks, Kairo. That's about what I expected. I think I'd prefer an even simpler solution like I describe in comment 29. Tom, can you please evaluate my proposal from comment 29 and let me know what you think. None of the language is final, but the the primary crash reporting notice would be a dialog with "yes, submit crash reports" and "no, don't submit a report this time". The opt in is for all crash submissions and the opt out is for this one particular crash submission. The "never ask again" choice would not be a part of the main UI but would be accessible from the Options panel switch, something like "[Enable | Disable] Firefox crash reporting".

Asa, your proposal in comment 29 seems asymmetric: it favors reporting over not-reporting. For a user who's no aware of the options panel, rejecting crash reports could be an annoyance, especially if they're sufficiently infrequent (or mid-task) and the user is only thinking about that particular report, not the general case. Would it be possible to take a symmetric approach instead?

In FxOS, we also favor reporting, FWIW, and very intentionally. We want people to send the data, but we need them to decide actively on that.

This is not much different from how the desktop crash reporter works, honestly. We persist the "send a crash report" checkbox decision there, but we show the UI every time. We default to checked because we want the minimum amount of interaction to let the user send a report and get back to what they're doing.

(In reply to Tom Lowenthal [:StrangeCharm] from comment #34) > Asa, your proposal in comment 29 seems asymmetric: it favors reporting over > not-reporting. For a user who's no aware of the options panel, rejecting > crash reports could be an annoyance, especially if they're sufficiently > infrequent (or mid-task) and the user is only thinking about that particular > report, not the general case. Would it be possible to take a symmetric > approach instead? It absolutely favors reporting over not reporting. That's an explicit goal of the proposal.

On this story, I don't know of an easy way to do #6. I'd suggest we punt on that for v1 and potentially file a follow up to investigate.

User Agent : Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:25.0) Gecko/20130717 Firefox/25.0 Build ID: 20130717030207 Tested for iteration 10 on latest nightly from ftp://ftp.mozilla.org/pub/firefox/nightly/2013/07/2013-07-17-03-02-07-mozilla-central/ using windows 8.1 preview. I am getting expected result. Firefox didn't start automatically after crash. I followed same steps as given in user story.