Spinning this off from Bug 358082#c36. I think about this quite a bit when I read hendrix comments, especially when the "call out" the verbiage in their hendrix report.

I agree. Rather than "Crash Bang Boom" I would like to see an apology ("We are sorry, but Firefox has experienced a critical internal error and has had to shut itself down" or whatever) along with something like "This was not your fault". An apology seems natural, and I've found when dealing with 'normal' (not techy) people, a sentence underlining the fact that this was our fault rather than theirs helps placate them towards us. And then launch into something like "In order to help us make Firefox a better product for you, please submit the following data relating to your crash so Mozilla engineers can understand why Firefox failed you in this instance. By doing so, critical problems can be fixed and delivered to you via Firefox's automatic update feature." Or something. It's humble, it's personal, it's an apology, it's accepting the blame and it's asking the user to help us help them.

(morphing title somewhat) (In reply to comment #0) > Spinning this off from Bug 358082#c36. I think about this quite a bit when I > read hendrix comments, especially when the "call out" the verbiage in their > hendrix report. You've mentioned this twice, but failed to actually provide links to when this happens. Care to share? Is it a deluge of anger or just the normal trickle? (In reply to comment #1) > I agree. Rather than "Crash Bang Boom" I would like to see an apology ("We are Like the one that reads "We're sorry, Firefox hit an unexpected problem and crashed." right below the "Crash Bang Boom!" text? Would "Oops!" be any better? How about "It's not you, it's me"? Or "Don't Panic!" > sorry, but Firefox has experienced a critical internal error and has had to > shut itself down" or whatever) along with something like "This was not your > fault". An apology seems natural, and I've found when dealing with 'normal' Adding something about it not being their fault would be good, yes. > (not techy) people, a sentence underlining the fact that this was our fault > rather than theirs helps placate them towards us. > > And then launch into something like "In order to help us make Firefox a better > product for you, please submit the following data relating to your crash so > Mozilla engineers can understand why Firefox failed you in this instance. By > doing so, critical problems can be fixed and delivered to you via Firefox's > automatic update feature." Or something. That's a lot wordy, IMO, and doesn't really say a lot more than what the current text ("To help us diagnose and repair this problem ..") does. Can we try to reword what's there to sound a little more personal while respecting the fact that the user's mindset at that time is *entirely* about getting back to where they were? I actually debated not including that section entirely, and just having the biggest part of the UI be a shiny button that said "restore my session, damn you!" > It's humble, it's personal, it's an apology, it's accepting the blame and it's > asking the user to help us help them. I agree that these are the tones we want to strike, but I think "offering to help the user get back to what they were doing" needs to be a higher priority than "asking the user to help us".

There was one Hendrix report in particular that both stevee and I saw that prompted this discussion. There has not been a deluge of comments, but there have been a few snipes here and there that made me think that maybe the verbiage was not going over that well. Crashing can be a bad thing if someone is in a critical point during their browsing session, and I just wanted to make sure that we are sensitive to that by not having the messaging be too lighthearted. Ideally, I would like to balance having the user get back to their work and have them help us, if it is possible to craft messaging that could convey both.

I'd like to argue that breakpad's crash bang boom shouldn't be worse than bugzilla's mid-air collision. It seems some of our (Bugzilla's) potential customers were airlines....

(In reply to comment #2) > > It's humble, it's personal, it's an apology, it's accepting the blame and it's > > asking the user to help us help them. > > I agree that these are the tones we want to strike, but I think "offering to > help the user get back to what they were doing" needs to be a higher priority > than "asking the user to help us". Questions: Is encouraging feedback is anything but a win for everyone? How is "helping us out" only helping "us", i.e. triagers and developers? Is a few seconds of users' time more precious than ours? Also, what about where the problem is an uncommon one or, in the extreme case unique to the user? For these, should not the message in fact encourage feedback? Why not help or encourage the user to make an informed choice, as per Marcia, "I would like to balance having the user get back to their work and have them help us, if it is possible to craft messaging that could convey both."

I, too, object to "Crash! Bang! Boom!" I think it comes across as sarcastic, as if the coders are making fun of the user. (I.e. a joke.) I can see somebody saying those words with a silly grin on their face, shaking their finger as they remonstrate the user for what they did. I think it's unprofessional and gives the wrong opinion of the product. (At least it does to me and those people who do object to it.) Whenever I've had SeaMonkey crash on me, I've been in the middle of something "important" (compiling daily bug reports for Mozillazine), and the crash has ended up causing me extra work because my visited link history gets buggered up and I can no longer easily tell which bugs I've already reported or not. So, reading that dialog box just makes me more upset about the situation than I already am. My apologies if I'm just repeating what people have already said, and if it's already agreed that the text needs to change to something else. For the initial text, I'm quite partial to Steve's first suggestion in comment one: "We are sorry, but [Product] has experienced a critical internal error and has had to shut itself down." (I say "[Product]", because this should cover more than just Firefox.) As for asking for feedback - is there any reason why we need to ask at all? Can't we just silently submit a crash report regardless? How much of a time lag is involved in a report being submitted? Would users actually notice that it's taking longer than normal to restart? Are there privacy issues that would prevent us from being able to do this without their, assumed, permission?

As a side note, Seamonkey has crashed on me approximately 10 times in the last week, using various nightly builds over that period of time. In each case, there have been two things that the crash dialog has "promised" that have failed to work: In no instance were my tabs ever reopened on restart. Is the code to re-load all tabs actually part of SeaMonkey? If not, the message displayed on crash that the browser will attempt to reload the tabs should not be displayed if a crash happens with SeaMonkey. (Perhaps this is only something that Firefox does, and the message was simply ported without editing to SeaMonkey?) Also, when the crashes did happen, SeaMonkey has always been unable to actually submit a bug report. In every instance, I've been told "Failed to submit crash report." I'm assuming that this functionality isn't supposed to be broken under SeaMonkey? (Or are there certain types of crashes where reports cannot be filed? If so, the crash dialog should be changed to indicate that a crash report will be *attempted* to be filed.) Do I need to file a SeaMonkey specific bug on this? For both tab reloading and crash reporting, since this message bug isn't targeted against a specific product, the message should be modified to include only the functionality of each product that's being run...

We need to find better text here, but beltzner and I agreed this isn't ideal. Requesting blocking.

If this isn't blocking1.9, could it be wanted1.9?

I believe this is going to be fixed as part of bug 404855 (see attachment 297804 [details] [diff] [review]).

Fixed in bug 404855.