Closed Bug 626818 Opened 13 years ago Closed 11 years ago

Add an option (under the Report dropdown) that focuses specifically on Plugin crashes

Categories

(Socorro :: Webapp, task)

x86
macOS
task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: marcia, Unassigned)

References

()

Details

I seem to recall higher numbers showing in the default summary view (i.e. we were showing "All" crashes instead of just "browser" crashes.

I like to see the "all" number of crashes since that gives us a better representation of the real total numbers.
chofmann mentioned that he actually asked to make this change. Another reason is that I have to drill down another level if there happens to be an explosive crash that isn't classified as a browser crash.
I guess us on the user side of things need to make a decision on that. Who is the majority of users of this page? What is this group of people more likely to need there?
majority of users of the page are firefox developers wanting to find and fix firefox crashes.  there are fewer of us looking at the overall picture, and in wanting to understand and encourage plugin vendors to fix their crashes.

the idea wasn't to penalize plugin vendors or watchers of over all crash and hang activity, it was just to reduce noise of lots of plugin crashes for the bulk of firefox developers.

we could also set up a "plugin product" page like we have firefox, tbird, camino,... pages that would help to streamline the analysis of plugin crashes hand hangs.  see Bug 637661 for some ideas on that.
What Chris says ends up meaning we should close this one as WONTFIX or INVA - Marcia, do you agree?
5 of the top 10 Beta 12 crashes don't show in the browser crash view. I would actually prefer a pref that I could set for the default but if that cannot be done than I guess we can resolve as won't fix.
We could add it as an option (under the Report dropdown) and write a view and a TCBS calculation for it.  If that's the desired behavior, let's change the title of this bug.
I really like the idea of the "plugin product" page where we can give visibility to the stability world - as it's related to plugins. I understand Marcia's concern that we are not paying enough attention to these very real problems. I think we should wrap this into a goal of the Crashkill team - reporting the state of plugin crashes, spikes, analysis and such. In this context, we should think about what views/reports would be most helpful.
yeah, we can also tweek this view to show versions of flash involved with the signature in addition too, or rather than the firefox versions.

here is an example

http://people.mozilla.org/~chofmann/crash-stats/20110228/top-plugin-crashes-40b12.html

this kind of report would quickly surface things like this where the #4 signature is only seen on a couple of 10.2 versions, and indicate if a bug was on file.

#4 295	F1330478284___________ 	2+: 10.2.152.26 10.2.151.49 ...	632532 ...
chofmann, I like that idea. We can link to these types of reports in the bugs.
Summary: Which view is the default for https://crash-stats.mozilla.com/products/Firefox → Add an option (under the Report dropdown) that focuses specifically on Plugin crashes
smooney pointed me to this bug. I am intensely uncomfortable that we are hiding plugin crashes by default on the topcrash page. chofmann seems to be making the assmuption that plugin-process crashes are caused by plugins, which is simply false. This is especially important for "hang" crashes, which are *mostly* either Firefox's fault, or something that Firefox should work around in some way. I believe whatever change made the browser crashes appear by default should be reverted ASAP.
This bug is about trying to make the plugin crash and hang data more useful and actionable.

I think you want to advocate for changing the defualt in https://bugzilla.mozilla.org/show_bug.cgi?id=562216 which has been in place for several months.  I'm pretty sure I consulted with you when that change was made.
Component: Socorro → General
Product: Webtools → Socorro
Component: General → Webapp
We have this.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.