Closed Bug 542410 Opened 15 years ago Closed 15 years ago

KB Article: Plugin crash reports

Categories

(support.mozilla.org :: Knowledge Base Articles, task)

task
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: Dolske, Assigned: cilias)

References

()

Details

Over in bug 538910 I'm implementing the UI that's shown when a plugin crashes (with Out Of Process Plugins [OOPP], this no longer crashes the whole browser). Basically, the plugin's spot in the page is replaced with: [icon] The Foo Bar plugin has crashed Reload the page to try again. A crash report was submitted. The SUMO relevant bit of this is regarding the crash report -- we didn't want to have intrusive "do you want to submit a crash report" popups or checkboxes, so there will now be a checkbox in the browser preferences to control submission. In this UI, "crash report" should be a link to a SUMO page explaining what a crash report is, what it contains, how to disable report submission, etc. Basically, something like http://support.mozilla.com/en-US/kb/Mozilla+Crash+Reporter but specific to the context that users will be seeing it in. This new UI will land on trunk soon, and will be backported to Firefox 3.6.x as part of the "Lorentz" release plan. A placeholder would be sufficient while this is only exposed to nightly users. I'm using the app.support.baseURL pref to build the link, so I'll need something hanging off that location.
(In reply to comment #0) > I'm using the app.support.baseURL pref to build the link, so I'll need > something hanging off that location. Is that a help-topic link, like what we have for about:privatebrowsing? bug 471753 For situations like that, as well as "For Internet Explorer Users", "The Bookmarks and history system will not be functional", and the help link in each options panel, we need to add code to our htaccess file.
(In reply to comment #1) > > I'm using the app.support.baseURL pref to build the link, so I'll need > > something hanging off that location. > > Is that a help-topic link, like what we have for about:privatebrowsing? Yeah, same thing.
We will need a help-topic name. For instance, the private browsing one is "private-browsing". For Internet Explorer Users uses "ieusers", and The Bookmarks and history system will not be functional uses "places-locked". We will then take care of redirecting to the proper article using our htaccess file. For other examples, see <http://viewvc.svn.mozilla.org/vc/projects/sumo/branches/production/webroot/htaccess.dist?view=markup>.
Let's go with "plugin-crashed".
Assignee: nobody → bmo2010
Summary: Need SUMO article for OOPP crashes / crash reporter → KB Article: Plugin crash reports
If we were to make this article public right away, it would still show up in search results, making it a bad UX for current users on support, who would see just a placeholder. I think we would be better off making the article redirect to another one for now.
Redirect is up. Leaving this bug open until we have the final article up. I'll file the bug for adding this to the htaccess file.
Depends on: 544137
FWIW, current plan is to release a Developer Preview 2 with OOPP enabled next week. This bug doesn't block, but it would be nice to have a page specific to this issue as more users are exposed to it. Also, while I'm here, while talking with Faaborg the idea came up that we might want part of this page to include a list of support contacts for the top-N plugin vendors, so users can go complain directly to the cause of the problem. :)
Some thoughts: - The "Mozilla Crash Reporter" article walks the user through the crash reporter UI, and AIUI that UI does not apply to this use-case. - If I'm an average user, and I get this while trying to watch a video on youtube, and I click on the "crash report has been submitted" link, there are a few things I want to know.: * What is a plugin? * What is a crash? * What was submitted? * How do I fix it? To me, that's what the layout of the article should be. - We can include the options panel pref at the end or part of the "what was submitted" section. - re: list of support contacts; unless the user knows which plugin crashed, I don't see how that's helpful.
(In reply to comment #8) > Some thoughts: > - The "Mozilla Crash Reporter" article walks the user through the crash > reporter UI, and AIUI that UI does not apply to this use-case. Correct. The existing Crash Reporter isn't used, because the browser hasn't crashed in this case. > - If I'm an average user, and I get this while trying to watch a video on > youtube, and I click on the "crash report has been submitted" link, there are a > few things I want to know.: > * What is a plugin? > * What is a crash? > * What was submitted? > * How do I fix it? That looks like a good start. I would just add that as part of the "What was submitted" it should include info on how to change crash submission preferences. Crash reports involve privacy-sensitive info, so we want to make it easy for people to figure out how to turn it off if that's what they want. (Note that some updates to this stuff are going on in bug 550303 and bug 550293). > - re: list of support contacts; unless the user knows which plugin crashed, I > don't see how that's helpful. Oh, we're definitely letting the user know which plugin is being crashy!
(Bah, misclicked before I finished) ...the UI prominently shows the plugin name, because we want to make it very clear that (1) it's not Firefox that had a problem and (2) make plugin vendors more accountable for their problems. See http://blog.mozilla.com/dolske/2010/02/10/crashed-plugin-ui/ Bug 544597 will also help with tweaking the displayed name to be more appropriate.
Justin, can I steal that screenshot for the article? If I need more, is there a tool to reproduce plugin crashes on demand?
Sure. There isn't a superhandy way to test things, you can kill mozilla-runtime from the OS's process explorer / command line, although it shows a slightly different UI because it's not a real crash. I suppsoe one way is to load http://flashcrash .dempsky. org/, which currently causes the Flash plugin to crash (don't load URL unless you're using a OOPP browser!).
I've got a draft up at <https://support.mozilla.com/en-US/kb/*Plugin+crash+reports>. * It's currently in a staging area. You'll need to log in to see it. * Article bugs get marked as verified when the article is approved. As I understand it, the UI is going to change. We can update the article when that happens (it /is/ a wiki. :-) ) The last section is primed for a list of support contacts.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Cheng, Matthew, Michael, Could one of you review this? The staging copy is waiting for review. The KB version is currently redirecting to the Firefox crashes article.
Thanks, Michael!
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.