412633 - crash reporter should send list of installed plug-ins and their versions

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, defect, P2)

Description

[Samuel Sidler (old account; do not CC)]

Follow up from bug 366973. We should get installed plug-ins and their version as well.

Comment 1

[Benjamin Smedberg]

Schrep, I don't think this needs to be a blocker. Unlike extensions, we already collect the list of DLLs and version information, so the list of plugin metadata provides only marginally more useful information.

Comment 2

[Mike Schroepfer]

Re comment 1 off the list

Comment 3

[Justin Dolske [:Dolske]]

Attachment: Patch v.1

This was easier than expected. I wanted to take a shot at this, so that we might be able to better understand the impact of plugins on crashes... Reports already have a list of modules, but we don't know which are plugins are which are just plain old libraries / binary components.

Comment 4

[Justin Dolske [:Dolske]]

One thing I wasn't sure of -- other code in this file does some stuff with NS_ITERATIVE_UNREF_LIST which I don't understand. Do I need to worry about that here?

Also, over to Plugins, since this isn't really a breakpad issue. [Will file a followup afterwards to have this data exposed in Socorro, though.]

Comment 5

[Jesse Ruderman]

Does this include all installed plugins, or only the plugins used during the session/instance?

Comment 6

[Justin Dolske [:Dolske]]

It's all the plugins the browser knew about when it last updated it's cache; the list includes plugins that are blocklisted or disabled. We could grab the flags to know the plugin's state, but it didn't seem particularly useful at the moment. [If a plugin's disabled, it wouldn't show up in the list of loaded modules anyway.]

Comment 7

[(not currently active) Ted Mielczarek]

If you have the data easily at hand, I'd suggest including it. It's easier to have the data and not use it than to not have the data and want it.

Comment 8

[Benjamin Smedberg]

Yeah, I think it's much more interesting to know which plugins were actually loaded in the crashing instance than to know all plugins which may or may not have been loaded, but if we can get both then that's fairly simple. We can certainly add a couple of attributes to nsIPluginTag to make this possible:

  readonly attribute boolean loaded;
  attribute boolean outOfProcess;

Comment 9

[Justin Dolske [:Dolske]]

Hmm, from a quick skim of the code it's not at completely clear to me where we create the first instance of a plugin (to mark it as loaded and re-annotate the report). Does everything go through nsPluginHost::GetPlugin()? And IIRC we no longer ever unload plugins?

Comment 10

[Dave Townsend [:mossop]]

Comment on attachment 420257 [details] [diff] [review]
Patch v.1

Seems ok to me as-is though I think we should add a test, or do the better version that bsmedberg alluded to.

Comment 11

[Robert Kaiser]

This would make crash triaging significantly easier as the plugins are often hard to glimpse within the pretty large modules list.
Can this be picked up again?

Comment 12

[Justin Dolske [:Dolske]]

(clearing assignment of bugs I'm no long planning to work on)

Comment 13

[Benjamin Smedberg]

There are privacy issues here and I doubt we'd use this information regularly and effectively, so I'm going to WONTFIX this.