23856 - need to decide whether FCS will load plug-ins from Nav4 plugins directory, then need to implement decision

Status: VERIFIED FIXED

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

Description

[ekrock's old account (dead)]

This is a reminder bug filed by Eric, on Eric, to remind Eric that based on the
feedback we get to beta and the number of plug-ins that run with backward
compatibility, we must make a final decision about whether FCS will load
plug-ins from Nav4 plugins directory.

Comment 1

[ekrock's old account (dead)]

Marking M16.

Comment 2

[ekrock's old account (dead)]

Note related discussions of this issue in #21943, #21938, and #22463.

Comment 3

[ekrock's old account (dead)]

Bulk moving old [donttest] code to new donttest keyword. Sorry for the spam!

Comment 4

[ekrock's old account (dead)]

*** Bug 33584 has been marked as a duplicate of this bug. ***

Comment 5

[ekrock's old account (dead)]

Note additional discussions of this issue and options in bug 33584.

Comment 6

[ekrock's old account (dead)]

I'm currently leaning against doing load-from-Nav4 for beta2 due to the 
discovery that the Sun Java plug-in for Nav4 caused a crash this way for N6, 
demonstrating the possibility that other Nav4 plug-ins might cause N6 crashes as 
well.

Comment 7

[ekrock's old account (dead)]

Nominating nsbeta2. I need to review the options with plug-in engineering & 
reach a final decision on this; we need to do for beta2 what we plan to do for 
FCS. Due to the fact that backward compatibility is turning out to be a 
process of debugging one plug-in at a time, leaning towards either (1) forcing 
customers to re-download all plug-ins, or (2) only loading selected major 
plug-ins that we've certified to be b.c.

Comment 8

[leger]

Putting on [nsbeta2+][6/01] radar.  This work must be done by 06/01 or we may 
pull this for PR2.

Comment 9

[leger]

Changing from [6/01] to [6/15]

Comment 10

[ekrock's old account (dead)]

Setting to M17. Reviewing this issue in the newsgroups.

Comment 11

[Jim Roskind]

Cleaning status whiteboard by marking beta2 minus (6/15 has passed)

It would appear that the decision is to remain with the status quo :-/.  I don't 
know that folks will have time to change anything for beta2, as the team is 
pretty doomed with the current list of bugs.

Comment 12

[chris hofmann]

what are we doing now?
can we get a retest on this to figure out?

if plugin's are in marginal shape we shouldn't throw 
gasoline on the fire by loading every plugin we can
get our hands on, especially if we are going to load
plugins at startup...   that would be a good way to
drive MTBF down for lots of users...

recommend we turn of plugin loading of old plugins
and/or don't have the installer do migration..
just like we have done in every major release (3.x -> 4.x)

removing minus to get reconsideration.

Comment 13

[Peter Trudelle]

nsbeta2+, need a decision

Comment 14

[ekrock's old account (dead)]

Revising Summary to note that this bug tracks both the need to decide the issue 
and the need to then implement the final decision.

Working on the decision. I think we're agreed that to minimize risk, we're not 
going to load *all* Nav4 plug-ins blindly. However, I'm investigating the 
cost-benefit of possibly loading at least one or more widely-used plug-ins that 
we've already certified for backward compatibility. Details to follow.

Comment 15

[ekrock's old account (dead)]

OK, here's the deal.

1) It would be unwise to load *all* legacy plug-in binaries from the Nav4 
plugins directory because many are untested and the possibility exists that some 
might compromise the browser's stability. This is what we currently do on 
Windows, and that option is out, so the code must be changed to *some* other 
approach.

2) Loading *no* legacy plug-in binaries would force Moz/N6 users to do one of 
the following for plug-ins they already have and want to continue to use that 
aren't bundled with the product (Moz bundles none; N6 bundled plug-ins TBD):

a) (99% of the time for typical users) redownload & reinstall the plug-in, since 
typical end users haven't kept the installer and don't understand how to copy 
over a plug-in from one directory to another (chofmann, I understand that this 
is what we've done in the past, but Nav6 in 2000 faces a different situation 
than Nav4 in '97)
b) rerun the plug-in installer if they still have it (99.5% of users won't)
c) copy over the plug-in binaries from one directory to the other (though we 
could explain this in the release notes, most users won't know how to do this 
and won't read the release notes)

3) A compromise, in which Moz/N6 load from Nav4 plugins directory only a limited 
set of plug-ins that have already been proven to be stable and compatible, 
appears to be preferable. Real, Flash, and Acrobat are the three most 
widely-used plug-ins and each has already been qualified as backwardly 
compatible, so they are the obvious candidates for this list. Netscape is able 
to provide the resources for implementing recognition and autoloading of these 
three leading, qualified plug-ins; other plug-in vendors would of course be free 
to implement recognition for their own plug-ins if they wished to and to submit 
the patches through mozilla.org.

There are two ways to achieve (3):

3A) Hardcode the list of which plug-ins to load into the C code. Andrei's 
evaluation of work required:

3Ai)  10 minutes to do this on Windows
3Aii) probably a similar amount of time for someone who (unlike Andrei) is a Mac 
expert to do the same thing on the Mac [ this won't be done on Linux because the 
Motif-to-GTK GUI changeover issue has rendered Nav4 plug-ins obsolete ]

3B) Create a softcoded list of which plug-in files to load (example: as a hidden 
pref in prefs.js). The advantage of this approach is its greater flexibility. It 
would be easier for Netscape and Mozilla to add/remove plug-ins from their 
respective lists if the need arose. It would also be easier for plug-in vendors 
to add their plug-in to the list to enable testing and qualification, and even 
for advanced users to edit this themselves if they wished. The disadvantage is 
that of course this is an additional feature and requires more work. Andrei's 
estimate of work required:

3Bi)  1 day for him to implement and test this
3Bii) The build team would then need to configure the build process to produce a 
prefs.js on windows that listed the windows DLL filenames and a prefs.js on the 
Mac that listed the Mac plug-in filenames [ the list on Linux would be empty ]

As the PM for the Mozilla Plug-in API, I obviously prefer 3B, but since we're 
trying to clamp down on features, I'm willing to accept 3A. John Gable, as the 
PM for Navigator, has expressed a strong preference for 3B. Bottom line is that 
either course will likely require PDT team approval, so I suggest that we 
schedule the issue for discussion at a PDT team meeting ASAP, discuss this, and 
how much the PDT will sign off on. cc:ing John in case he'd like to add further 
comments.

Comment 16

[johng]

Andrew (av),  Eric and I were talking and you should go ahead and check-in your 
10 minute hack for Win and Mac to auto-load specified plugins from Nav4.  Let's 
get that code in asap - it has been nsbeta2+ approved.

Assigning to [e-mail], changing OS to All even though it only effects Mac 
and Win platforms.

Separately, we should also create a new feature request bug to solve this 
problem in a better way.  Specifically, a better solution would be to create a 
preference that lists all the plug-ins that Netscape 6 automatically loads from 
the older versions of Netscape.  That way as we test and discover which plugins 
work, it would be easy to add them to this list.  Also, plug-in vendors can more 
easily test their own plug-ins this way.

No one within Netscape engineering may have the time to implement this better 
solution, but someone on mozilla, perhaps someone working with one of the 
plugins companies, might.  It would be a big help to plugin vendors, so 
hopefully someone will do this.

Comment 17

[johng]

see bug 43179 for the help wanted feature request to implement this solution 
using a pref instead.

Comment 18

[av (gone)]

Checked in. Marking fixed to get it off my list. Eric, please reassign it with 
proper changes if we want this issue to be discussed further.

Comment 19

[shrirang khanzode]

This works fine on windows for realplayer and shockwave. Acrobat file loading 
problem still exists so cannot verify that acrobat files launch  using 4.x 
plugin. This is not working for mac at all (shockwave, realplayer). I get  a" 
Plugin Dpwnload" message. I wil lgive it a try again with tomorrow's build and 
comment. Thnx.

Comment 20

[shrirang khanzode]

same thing today(not working on mac)..Is this feature only supposed to work on 
windows? Thnx.

Comment 21

[ekrock's old account (dead)]

Steve Dagley reports that (1) this would be very hard to do on the Mac, and 
(2) it's easy for users to copy over plug-in executables to the 
Mozilla/N6 directory if we explain how in the release notes, so he recommends 
that we only do this on Windows. Given lack of time and resources, I think this 
is the way we'll leave it. Not ideal from a pp of behavior standpoint, but we're 
out of time for hard enhancements. 

Marking pp and relnote. Thanks for your thorough testing shrirang!

Comment 22

[shrirang khanzode]

marking this verified ( to get off the beta2+ radar) with a reminder to self to 
add this to the beta2 release note (for mac)

Comment 23

[Pulsebot]

Pushed by ffxbld-merge:
https://hg.mozilla.org/releases/mozilla-beta/rev/5acccfb7184f
[fenix] For https://github.com/mozilla-mobile/fenix/issues/23856: Remove deprecated layout_constraintWidth_default