Closed Bug 382538 Opened 17 years ago Closed 17 years ago

Crash Reporter client should include a field for user comments

Categories

(Toolkit :: Crash Reporting, defect, P3)

Product:
Toolkit
Component:
Crash Reporting
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9beta3

People

(Reporter: alqahira, Assigned: ted)

References

Details

(Keywords: regression) 

The current crash reporter UI has no field for users to supply comments; this was mentioned in bug 358082 comment 7 and bug 358082 comment 7 and was not rejected out-of-hand (but not fixed there, either), so here's its very own bug.
What comments end up being the most helpful from users when looking at the crash report data? I can't remember many times when this data actually got surfaced on the talkback reports page, but maybe I wasn't looking hard enough. Do we want to provide a pre-populated list of options to help when investigating the crash, or is a free-form field required?

From a design standpoint, we want to try and make it as easy as possible to provide the information, and make it clear that it's entirely optional.
i think common ones are: starting up, shutting down, restarting. probably upgrading, possibly coming out of hibernation.
The data is helpful because it often shows patterns that might not be otherwise apparent. See for instane http://talkback-public.mozilla.org/reports/firefox/FFTrunk/simple-crash-analysis.all which seems to say that the ntdll crash often happens on right-click.
prompting would help in two ways a) encourages the feedback and b) prompting in a structured but simple way aids the user in thinking through what they did and thus improving accuracy of the report.

adding to timeless' list:
"First time" doing/after/... _____________
just installed ____________
just changed ____________


(In reply to comment #4)
> http://talkback-public.mozilla.org/reports/firefox/FFTrunk/simple-crash-analysis.all
> which seems to say that the ntdll crash often happens on right-click.
 
keypress or click last used is a good one. For the simplest use cases, could breakpad prompt to capture a user's keypress or click and kick standardized, appropriate verbiage?  This would eliminate the 10-20 different ways for a user to type "modifier-whatever-key" and make subsequent visual and possible automated analysis easier.  I think bsmedberg's URL illustrates the case.
I remember a bug within the last three weeks where many of the talkback reports for it mentioned that the crash occurred while printing, although that's one isolated datapoint.
As someone mentioned (on another bug?), this is also very important for non-browsers, where we have no other data on what caused the crash.

(In reply to comment #7)
> As someone mentioned (on another bug?), this is also very important for
> non-browsers, where we have no other data on what caused the crash.

Indeed yes. You are probably thinking of Bug 358082 comment 8 item 2).  mailnews (Thunderbird+suite) is my main interest in this bug.

Perhaps neil and david can suggest some ideas or others who might make useful suggestions for this bug from the mailnews perspective.
I may be in a minority here, but I'd much rather have real free-form comments than a list to choose from.  You limit your data to the kinds of crashes you think you might see, as consolidated into a few general categories.  With crashes, every bit of data helps, and you never know what bit it might be, so you don't want to limit what you get.  A good beltznerian prompt above the box would be great, though.

In addition, I'd really like to see some sort of character-limit-checking on the field, if at all possible, so the user knows where his comment ends and what won't be included in the final report; I've had issues with useful-sounding comments that are a bit too detailed and get cut off before the final payoff.
I agree with Smokey. Free form comments have been very useful when analyzing the top crash reports to try and determine what might be the cause. A pre-populated list might discourage users from giving, in their own words, reasons for the crash. I also use the comment field when testing crash bugs and attempting to get a full stack. I simply put "bug ######" in the comment field and know that it'll be easy to look up later.
I don't think anyone suggested eliminating free form input. I too would argue against that. 

I wrote "guided" but by that I don't mean a process that limits choices but rather adds a list of optional choices that can serve as hints in addition to providing structured input. I can't imagine that well worded hints or choices would *on balance* hurt or discourage user input, especially when you consider the extremely low percentage of people that chose to give free form input today.  Can anyone hazard a guess - 5% maybe?

On the contrary, if it's kept simple and well designed I think it would improve the rate and quality of responses.
Beltzner and I talked about this a week or two ago. This is a critical bug from a QA standpoint and should block the release. Requesting blocking.
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9+
Priority: -- → P3
I really think this bug should block beta 2. It will potentially require adding new strings (assuming the crash reporter is getting localized) and will help us identify causes of topcrashes.

I'm marking this as P1, from a QA standpoint and upping it in this bug as well. If that's not the proper way to do this (having read the meeting notes, I'm unclear if QA can set priority), feel free to set the priority back to P3.
Priority: P3 → P1
Priority: P1 → P3
This and bug 384207 will both have l10n impact.  I'm not sure when our string freeze is, I think I heard we're doing a soft freeze (soft serve?) at M10 and a hard freeze at M11, but I could be wrong.  I'm going to get bug 384207 in for M10, so I might be able to do this while I'm hacking on that anyway.

String freeze will be 2 weeks before the tree freeze of the last beta, and other than that, the earlier, the merrier. We'll try to throttle down the amount of string changes going in.
sounds important enough that this can be bumped up in priority.  Ted, can you make this bug a P1?  at the very least, a P2?
Assignee: nobody → ted.mielczarek
Blocks: 404855
Regarding the use cases for this feature: I have used this extensively for Firebug in two ways: 1) I mark my own crashes "firebug 1.2aX hunt XX" for example while I am trying to figure out why XX is crashing, reducing testcases, and looking for workarounds. 2) I ask users to mark crashes "firebug" so we can find patterns. 

Yes, having all of the extensions and their versions would be nice, but this is not an alternative.  Users often know what extension they were using, making the search on comments containing "firebug" much less noisy.

Also, the secret ability of Talkback to remember the URL field is very helpful.  So I often set the URL field to the feature I am working on, "firebug 1.2aX dynup" for example.  Then in the crash I set the comment fields to something specific "got past compile, flush on" or so. Then when I search talkback for "firebug dynup" I see progress.

Note that Firefox is now very stable for regular web pages so I guess more crashes are related to extensions.  I believe that firebug related crashes are now on the top crashers list for example. So think about the design for users of extensions as well as vanilla users.  Maybe a check box "I think this crash may be related to: []Firebug 1.1 [] colorzilla ...


It would be nice if when comments are implemented (both in client UI/front-end and in the reports we see via socorro), we end up with clean handling of non-Roman comments.  

Right now it seems like Talkback client is using legacy encodings when capturing the comments (at least on the Mac). When you see a report on the server, the comment text is gibberish, and, at least for the ones I've seen, autodetect won't detect due to the preponderance of Roman chars, so you have to guess/fiddle with the text encodings to get the comments to display correctly.  If we could ensure UTF-8 throughout the ecosystem, that would be great.

I'll be happy to file a follow-up bug on this if that's more appropriate....
Smokey: I'll try to take care of that in the implementation here.  I'll probably need some help testing.

Fixed on all platforms.  Should be UTF-8 on all platforms and in the database, and the clients will stop text entry at 500 UTF-8 bytes, so there shouldn't be any overflow issues.  The server stores and displays comments now, so testing would be great, file followups on anything you find.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9beta3
Depends on: 415016
Ted, I filed http://crash-stats.mozilla.com/report/index/0d5fa930-cf7d-11dc-8af2-001a4bd43ed6 today with the same build Marcia used in bug 404855 comment 73 (and it had the new UI), and as you can see, my 500 characters of UTF-8 comments are not showing up on crash-stats :(
(In reply to comment #21)
> Ted, I filed
> http://crash-stats.mozilla.com/report/index/0d5fa930-cf7d-11dc-8af2-001a4bd43ed6
> today with the same build Marcia used in bug 404855 comment 73 (and it had the
> new UI), and as you can see, my 500 characters of UTF-8 comments are not
> showing up on crash-stats :(

Bug 415170, now that I'm not so tired and did more checking.
You need to log in before you can comment on or make changes to this bug.