550668 - nsIPluginTag should expose fullpath

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Mike Hommey [:glandium]]

Attachment: Patch for 1.9.2

Before bug 488181, it was possible for e.g. components to get the full path for individual plugins. As noted in comment 9 there, one could use pluginreg.dat for that, but parsing it is a complex task. On the other hand, the data is just there in an attribute of the nsPluginTag class.
This information is useful for Debian, where we added an extra component that dumps extensions and plugin informations to dump to bug reports we get from users. Having the full path allows to also know what package the plugins are from if they come from a package.
"navigator.plugins" uses another class, which means the proposed change would not make the full path available to web pages.

Comment 1

[Mike Hommey [:glandium]]

Attachment: Patch for trunk

Same patch, but for trunk, where nsPluginTag moved in a separate file.

Comment 3

[Dave Townsend [:mossop]]

Pushed to trunk, this needs approval before it can land on branch: http://hg.mozilla.org/mozilla-central/rev/c7a4f2c4ba7a

Comment 4

[Mike Hommey [:glandium]]

I'm starting to wonder if the 1.9.2 change shouldn't add a nsIPluginTag_1_9_2 interface, actually.

Comment 5

[Justin Dolske [:Dolske]]

Yes. The current patch would break binary components using this interface.

Comment 6

[Justin Dolske [:Dolske]]

(to be clear: it's an incompatible change for binary components compiled against the current interface on 1.9.2. The trunk patch is fine)

Comment 7

[Mike Hommey [:glandium]]

Attachment: Patch v2 for 1.9.2

Implement a nsIPluginTag_1_9_2 interface

Comment 8

[Mike Hommey [:glandium]]

Comment on attachment 439880 [details] [diff] [review]
Patch v2 for 1.9.2

At this point, it's just pointless to add to 1.9.2.