25003 - LiveConnect needs to allow for testing for NAV4 plugins

Status: VERIFIED WONTFIX

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

Description

[Jascha Franklin-Hodge]

It is well understood that Mozilla does not support LiveConnect with NAV4 
plugins (See bug #18838).  Unfortunetly, it does not behave in the 
expected/desired manner in this circumstance.  If I have a NAV4 plugin called 
thePlugin on a page the test "document.thePlugin==null" results in false.  I 
suggest that the correct behavior for a NAV4 plugin is to return true for this 
test.  Because the behavior under Mozilla is to ignore LiveConnect calls made 
to NAV4 plugins, it is necessary to have the ability to test for non Live 
Connectable plugins so that the JS code can work around this limitation.  
Returning null for the plugin object seems like a good way to do this (it is 
currently how some other browsers that don't support LiveConnect, such as IE 
for Mac, behave).  If there is a better way to do this test, that's fine too, 
but there needs to be some way.

-jascha franklin-hodge
manager of server engineering
spinner.com/america on-line

Comment 1

[rogerl (gone)]

I don't think this is a LiveConnect/JS Engine bug, but let me know if there's 
something I need to do to help out.

Comment 2

[ekrock's old account (dead)]

You've raised a good issue, but the problem is this: how would Mozilla figure
out whether a given plug-in binary running within it would support LiveConnect
or not? I can't think of a way that Mozilla could inspect (really introspect) an
arbitrary plug-in binary and determine whether it was a Mozilla-ready plug-in
binary in which LiveConnect would work. (Suggestions welcome!) And if there's no
way that Mozilla can determine whether a plug-in binary is Mozilla ready by
direct inspection, Mozilla would have to have an internal list of every known
plug-in and an identifying string for navigator.plugins by which the
Mozilla-ready version could be recognized. (e.g. "FooPlayer GX isn't
Mozilla-ready, but FooPlayer XL is," etc.) With a vast number of plug-ins in
existence, arbitrary naming schemes, and differences in implementations across
platforms, I don't think that's realistic.

I'm open to all suggestions for a clever solution here! ;->

Realistically, though, I think that what will have to happen is content sniffing
for (1) the browser and (2) the plug-in version from navigator.plugins. e.g.
Mozilla may not have a complete database of all Mozilla-ready plug-in binary
names built-in (and such a DB would be out-of-date the day it shipped), but if a
content site makes the decision to use FooPlayer content, then it will know and
care enough about FooPlayer to sniff the browser, recognize Mozilla, and then
sniff the plug-in, recognize FooPlayer version X, and display one of two
messages or redirect, either taking you to the content directly if your browser
is capable, or showing a "Sorry, you need FooPlayer version N to fully enjoy
this content; download from here ..."

See the Ultimate Client Sniffer at
http://developer.netscape.com/docs/examples/javascript/browser_type.html for
sample client-side JS code for browser client sniffing.

Andrei, you're free to mark this FUTURE if you can't get to this (which I
suspect will be impossible anyway unless someone has a bright idea!).

Comment 3

[ekrock's old account (dead)]

I don't believe that there's a programmatic way that Mozilla can inspect a 
plug-in to determine whether or not it's a legacy Nav4 plug-in or an updated 
Mozilla plug-in. I think the only solution here is explicit sniffing from 
JavaScript of the browser version and then the plug-in version (presumably 
through document.plugins, see bug 9392) to recognize which plug-in version it is 
and behavior appropriately. Marking WONTFIX as a result.

Comment 4

[shrirang khanzode]

v

Comment 5

[Pulsebot]

Pushed by ffxbld-merge:
https://hg.mozilla.org/releases/mozilla-beta/rev/05fa7d2b78b2
[fenix] For https://github.com/mozilla-mobile/fenix/issues/25003: Pop back stack on main thread.