Closed Bug 411425 Opened 17 years ago Closed 13 years ago

Email (automatic reply) or tell users how to fix the crash they just encountered

Categories

(Socorro :: General, task)

Product:
Socorro
Component:
General
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: samuel.sidler+old, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

Reported by morgamic, Nov 29, 2007 When a user's crash report is attached to a bug that was fixed in a major release? Provide a way to send user notifications. For example, query a certain build, crash, date range -- get a list of emails, and either the web app or a user can automatically or manually send the notification to users about the updated release.
I know we talked about this, but we should also be able to (automatically?) email users if their crash is due to a bad extension or plugin. Would help with things like bug 422018 where the user has overridden compatibility checking and is now crashing.
I mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=422018#c12 another suggestion that might help solve this problem. on restart from a crash list out the 4 or 5 known things that can help reduce or eliminate crashes. the thing we found with trying to do e-mail auto response in the past is that: 1) only a small pct. of people actually provide e-mail addresses so the response rate it small, 2) it has been pretty painful to set this up and manage it for crashes that we know about and have confirmed answers for. I agree that the restart on a crash info page is less targeted, but it seems like it might be easier to manage and might have greater impact in getting the word out about work arounds.
I don't think we can do this unless we change the client UI to notify people that "hey this might cause you to get email later". I'd vote for WONTFIX.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
Target Milestone: --- → 0.9
It says "Email me when more information is availble", and the email address is purely opt-in. I don't think this should be WONTFIX. If we're not going to do this, why are we even bothering to collect email addresses?
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
yeah, what are we going to do here. current, we aren't following through with the commitment we ae making to notify the user when a fix is avaiable... the suggestion in comment 2 would go a long way to notifying users, and reducing the factors that lead to instability and crashes... lets think about trying to get a loadthispageaftercrash page solution in place.
Flags: blocking1.9?
changing summary to be more reflective of what is most valuable.
Summary: Email a user when a related bug is fixed → Email or tell users how to fix the crash they just encountered
the other factor in this is that a very small percentage of users provide e-mail addresses. haveing the restart page show the steps that can make their system more stable is a much more effective way on reaching a larger number of users and reducing the number of total crashes.
(In reply to comment #4) > It says "Email me when more information is availble", and the email address is > purely opt-in. I don't think this should be WONTFIX. If we're not going to do > this, why are we even bothering to collect email addresses? I agree that this shouldn't be WONTFIX. If we, f.e., discover that a stack is indicative of a problem which can be avoided, we could mine those reports for email addresses and email the list of people who did opt-in. Re comment 5 and comment 7, while a restart page would be useful, we'd have to make changes to Firefox to point users there after a crash, and we'd have to localize it. Our current release schedule doesn't allow for either of those activities, so I don't think this can block.
Flags: blocking1.9? → blocking1.9-
Target Milestone: 0.9 → ---
Seems like this is dependent on: * are we sure we want to do this * what is the user workflow for this type of reporting?
Severity: normal → enhancement
If we're not going to ever email users, we should just get rid of the email field and remove it from the client too. I don't really care, but I'd rather not have UI in the client for something we're not going to use.
I agree with ted in comment 10. A restart page is a much more effective tool in helping users to understand their crash, than e-mail notifications, since it reaches all crash reporters, not just the small number that send us an e-mail address. for the majority of stack traces we also don't have diagnosis available either (just the top 20-30 of hundereds of different stack signatures) so in these cases there is nothing specific to tell the user in e-mail. the only value to having any e-mail addresses is the very infrequent use to contact users to try and get more details. most of the time this is not very effective in diagnosing problems. If they have useful information they will send it in as comments inside the blackbox.
I disagree that there is only one value to having the email address - tho that may be true from a developer perspective. And I disagree that if they have useful info it will be in the comments - look at the low comment rate, and the quality of comments. A high percentage (half?) stink. Additional points: * + side: if people know they will get a response it may encourage them to continue submitting reports * + side: could it be used to encourage people to write comments? * + side: it's a real opportunity to connect with a class of users that won't file bugs. Perhaps thanking them might even garner some new volunteers. * - side: it can be a real long time til a bug is delivered (not just fixed) * - side: there isn't always a 1:1 relationship of stack:bug# Since I mentioned comments, I'll add that it would be nice if reporter encouraged comments - in my case for Thunderbird crashers. Right now frankly there's a disincentive - it's an opt-in rather than an opt-out. I forget what I calculated it to be - something like 1% of TB trunk crashes have comments. Perhaps it should be an opt-out when the crash has is no URL?
I am morally opposed to making the user make any more decisions in the crash reporter UI. Crashing already sucks, one of my big motivations for working on this was how dreadful the Talkback client was, with its wizard and multiple steps to go through. Users should be able to click "restart firefox" and be back in business ASAP.
agree with ted again. > * + side: if people know they will get a response it may encourage them to > continue submitting reports The might be try but there is evidence to the contrary. We haven't been sending individual e-mail responses or auto responses and the volume of incoming submitted reports continues to be more than we can manage and use for analysis. The flip side is also possible. If people continue to get untargeted auto responses from us they might actually be disincented to send in reports. > * + side: could it be used to encourage people to write comments? Not sure I follow how this would work. If people go to the trouble with adding an e-mail address I think they are likely to add comments, if they can think of something that might be helpful and they are able to articulate what is going on at the time of the crash. If they have just provided an e-mail, and we contact them 1, 2, or more days latter the circumstances around the crash are even more likely to be fuzzy in there minds. > * + side: it's a real opportunity to connect with a class of users that won't > file bugs. Perhaps thanking them might even garner some new volunteers. Sure, we could harvest e-mail addresses from the crash system to help on non-crash related activities. However, I think there are other ways that we can do this that are more respectful of the time and privacy of the individuals submitting the crash report. If people know that we might mail them on non-crash related topics such as community building I'm guessing that thay might actually drive crash reports submissions down.
How about only exposing the email field to alpha/beta/nightly users and for releases have it hidden? This hides the email field from the casual user and keeps it exposed to users who opted into testing.
Doesn't seem worth the effort, as we'd still have to have some sort of email reporting in place. Either we make it useful enough for the general population, or we get rid of it.
Since removing email seems to be quickly headed to the crapper ... I'm not particularly in favor of giving such feedback about fixes to the user ... I doubt it's worth the effort. My comment 12 was simply to flesh out more of the issues. But removing the email address doesn't necessarily follow - it's a separate matter involving different issues and different people.
We don't have their email and this isn't a great user experience. If we can prove that users would use this, we can revisit it -- but getting them to submit a crash at all is work enough in 90% of the cases.
Status: REOPENED → RESOLVED
Closed: 17 years ago → 15 years ago
Resolution: --- → WONTFIX
We just got this mail on the support list, and its reflective on the ongoing experience users have. We should fix this user experience that implies we will contact the users... Wow! Another crash. Oh, that's right, it's Firefox. What a shame, great browser, IF YOU DIDN"T HAVE TO RESTART THE F*(K!~G THING AT LEAST TWICE A DAY. I'm seriously contemplating if the IE browser I detest might be less hassle. It's not just me. Look at all the online complaints about Firefox crashing. And those bull$h!t "Tell Mozilla about this crash so they can fix it" and “Email me when more information is available” check boxes. Is that just to pacify, making us think somebody cares enough or is really knowledgeable enough to fix it. No fix yet & damn sure no email responses from you EVER. If it were a paid thing I'd be LONG GONE. Exasperating! Sorry for the negative tone, but this is SO old. This problem goes on and on with no apparent fix & I’ve NEVER gotten ANY kind of response from Mozilla.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
+1 for fixing this, but let's tackle it a little later this year once we get over the current obstacles.
Target Milestone: --- → 2.1
Speaking from a support perspective: We should email people as soon as they opt in; they expect an email given the UI. I personally think we should send out something that gets the following across: 1) We got your report, click here to access it. 2) Support for your specific crash signature is at http://support.mozilla.com/kb/XXXX (if we have an article) OR You can get help with Firefox crashes from http://support.mozilla.com/kb/Firefox+Crashes -- if we're definitely not processing all the reports, maybe just the latter. 3) We will contact you again if we need more information or help reproducing. Click here to opt out. 4) Don't reply to this email, see support for more help. I would NOT say that we will email you if we fix this crash in an upcoming version of Firefox. That sets the expectation that all crashes are to be fixed by the Firefox team and that's simply not the case since a good number of crashes are extensions/plugins/viruses/antiviruses/one-off. If we do know a crash is to be fixed in a future version, we can update the appropriate KB article.
Awesome work Cheng. Julie from Legal adds: "Emails should: --have a clear subject line that is not misleading as to purpose of the email; --have a link to our privacy policy in the bottom; --have a link where the recipient can unsubscribe from future emails; --have Mozilla's name and address in the body of the email. We should think about where these emails are stored to ensure there is adequate security around that. Here is the commitment we make about who sees these email addresses: Your email address and the URL of the site you last visited are only available to its employees, contractors, and selected contributors who signed confidentiality agreements that prohibit them from using or disclosing such information other than for approved Mozilla purposes. We should ensure this is followed."
in addition to a link, we're going to need a way for people to unsubscribe by visiting a well known mozilla.org server and entering their address and a token that's included in the email. I get a lot of misdirected email because people can't spell their email address correctly. I do *not* trust links i receive in email, so I expect to be able to go to the company's web site and find a way to complain or opt out. this probably means that the bottom of our privacy page should include a link for opting out of such stuff. i think the privacy policy should probably also be updated to mention this email so people are aware of it and can rely on google to reach the policy and opt out.
How is this going to work for non-Firefox products, e.g. comment 21 item 2 isn't relevant for anyone but Firefox. Also, looking ahead, how is this expectation (In reply to comment #21) > Speaking from a support perspective: > We should email people as soon as they opt in; they expect an email given the > UI. going to be met for "EOLed" products (when Socorro tells the client to stop sending reports; I'm not sure what the client-side UI looks like for that)? I.e., user expects email, but no reports are being submitted even though the user goes through the motions, so user never gets email for crashes they "report" after the stop-sending command.
(In reply to comment #24) > Also, looking ahead, how is this expectation > going to be met for "EOLed" products (when Socorro tells the client to stop > sending reports; I'm not sure what the client-side UI looks like for that)? > I.e., user expects email, but no reports are being submitted even though the > user goes through the motions, so user never gets email for crashes they > "report" after the stop-sending command. Once the stop-sending command is sent (and Socorro does not currently support sending it) the crash reporter will display a dialog indicating that the product is end-of-lifed instead of the normal UI.
This is important especially for crashes caused by 3rd party add-ons. I hope this auto-reply feature would minimize the damage to Mozilla products' reputation.
Summary: Email or tell users how to fix the crash they just encountered → Email (automatic reply) or tell users how to fix the crash they just encountered
re comment 26, on average we do not know if a problem is caused by a third party, unless it happens to be "your Flash plugin crashed", in which case we already have a solution for that.
I wrote a possible message in Bug 511756 Comment 56: > Thank you for sending your Firefox crash report. > > According to our crash database, your crash was caused by the Trend Toolbar > add-on you had installed. To resolve the issue, please install the hot fix > provided by Trend Micro: > http://esupport.trendmicro.com/pages/My-Firefox-web-browser-crashes-while-browsing.aspx > > We hope this helps you enjoy better browsing with Firefox. > > - The Mozilla Crash Reports Team
Another addition to the email in comment #21: if we know the crash was plugin related, we can send them to plugincheck.
We could talk to the AMO people about how they are using RabbitMQ and Celery. Using that as a queue to pile up email jobs and send them out might be worthwhile.
I got started by reading the docs: http://ask.github.com/celery/. davedash wrote some more about it here: http://jbalogh.github.com/zamboni/topics/celery/
Target Milestone: 2.1 → 1.9
We'll be moving forward with this idea with a goal of getting this in place in Q3. See https://wiki.mozilla.org/PostCrash for an overview (more details to come soon).
All right, new requirements: 1. When a crash that has an email address is submitted, add signature + email to a queue 2. Create a job that: 2.1 Takes an item from the queue 2.2 Checks to see if we know of a SUMO article for this crash (cache URLS in a table) 2.3 If not, search SUMO for an article 2.4 Emails the user with support information Email should provide ability for users to unsub from further emails, so we also need a second table of "people not to email". Cww or Michael Verdi will supply text of email. For a queueing system, we might like to use Celery as opposed to putting more load on either of our storage systems. For email investigate use of Basket.
Assignee: nobody → ryan
Blocks: 585593
I'm concerned that only correlating by crash signature will lead to unhappy results in some cases, but perhaps it is good enough.
(In reply to comment #34) > I'm concerned that only correlating by crash signature will lead to unhappy > results in some cases, but perhaps it is good enough. yeah, I think this should/will only be used in a limited set of cases where analysis has been done to link a signature with specific steps that can be taken to avoid the crash.
(In reply to comment #35) > (In reply to comment #34) > > I'm concerned that only correlating by crash signature will lead to unhappy > > results in some cases, but perhaps it is good enough. > > yeah, I think this should/will only be used in a limited set of cases where > analysis has been done to link a signature with specific steps that can be > taken to avoid the crash. I'd really like to be able to tag certain well-known, distinct signatures related to certain third-party hacks, provide a brief explanatory message, and add the signatures+message set to the queue, so that every time Camino users crash due to these hacks, those users can be provided with info on how to stop the third-party hacks in question from crashing Camino.
I think that SUMO articles only match a search for signature when a human being has made that correlation - Cheng, can you confirm?
Assignee: ryan → nobody
We've made this available thorugh the Postcrash project: there are more specific bugs for some parts of it still open.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 13 years ago
Resolution: --- → FIXED
Component: Socorro → General
Product: Webtools → Socorro
Blocks: 506338
You need to log in before you can comment on or make changes to this bug.