Closed Bug 562221 Opened 15 years ago Closed 8 years ago

Need ability to mark signatures as caused by "3rd parties" and filter those in or out for all reports

Categories

(Socorro :: General, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: christian, Unassigned)

References

Details

Need ability to mark signatures as caused by "3rd parties" and filter those reports in or out. It would be great to have a way to define a crash signature as "3rd party", perhaps attaching some notes as well. When looking at crash reports, I personally don't want to see the 3rd party issues (when deciding which crashes to fix in an update). Sometimes I may want to see them though (perhaps for adding to a blocklist or looking for issues to work around on our end). Examples of 3rd party issues: * Buggy skype plugin causing crashes * AV mistakenly deleting Firefox resources, causing it to crash * Linux vendors roll out a busted custom version of Firefox As a bonus, perhaps the oopp hangs/oopsies could automatically be marked as 3rd party.
maybe this special status could come from surfacing more info from bugzilla. along with the bug number we could import bug product/component In this case where we want to filter skpye crashes the way they would be weeded out of the report would be to "don't show signatures that have associated bugs with product/component matching "Firefox/Extension Compatibility" [@ SkypeFfComponent.dll@0x440c3 ] & [@ @0x0 | SkypeFfComponent.dll@0x440c3 ] from the top crash lists based on the the fact we have https://bugzilla.mozilla.org/show_bug.cgi?id=546632 on file. It gets a bit more complicated if we have multiple bugs with multiple components, and in that case we might want to fall back to showing the signature if any conflicts in status/product/components arise. By using bugzilla status/product/component/ and other fields for the kind of query results or topcrash list production we avoid the info getting out of sync and making some bad decisions based on that. An example is if someone discovers that the problem really is in the NPAPI and not skpye the bugzilla product/component gets changed, but someone would manually need to go change the socorro "special status" field. Better to keep these tracked in a single location.
Blocks: 580457
Component: Socorro → General
Product: Webtools → Socorro
website annotations have been a set of possible future features for a while. we are unlikely to implement this specifically, however.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.