468678 - remove support for resource (.rsrc) files in Mac OS X plugins

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Josh Aas]

We should remove support for resource files as a way for plugins to give data to the browser on Mac OS X. Plugin vendors were informed of this change in August of 2008. Barring any major complications, this change should take effect in Gecko 1.9.2 (or whatever comes after 1.9.1). Plugins should be bundles with plist files communicating the information that resource files used to communicate.

Comment 1

[Josh Aas]

Attachment: fix v1.0

Comment 2

[Steven Michaud [:smichaud] (Retired)]

Comment on attachment 352164 [details] [diff] [review]
fix v1.0

This looks fine to me.

I tested it on my old PPC G4 Mac with (mostly) the examples from bug
467417 comment #2.  I didn't have any problems.

But one of the URLs in that list has already disappeared (the
Silverlight example), so I had to replace it with a new one.  So
here's the list over again, with the new Silverlight example:

1) Flash 9.0 r124 (installed by Apple)

   http://rogerdean.com

2) QuickTime 7.5.5 (installed by Apple)

   Movie trailers at http://www.apple.com/trailers

3) Silverlight 1.0 (last version to support PPC)

   http://silverlight.net/samples/1.0/Grand-Piano/default.html

4) Real Player 11.0

   Movie trailers at http://www.film.com/movies/trailers

5) Flip4Mac 2.2.1.11

   Examples at http://www.windowsmedia.com/MediaGuide/Home

Comment 3

[Josh Aas]

pushed to mozilla-central

http://hg.mozilla.org/mozilla-central/rev/4e748930c3c6

Comment 4

[Steven Michaud [:smichaud] (Retired)]

Josh, we somehow both missed that this breaks Flash and Java :-(

The breakage only occurs if browsers containing this patch need to re-write the pluginreg.dat file.  But from that point neither Flash movies nor Java applets will load.  See bug 469510.

Comment 5

[Bill Gianopoulos [:WG9s]]

If this is backed out to fix the issue in bug 469510, then I think after getting conforming versions of Flash and JAVA released, the next time this is checked in, the code needs to ensure that if you switch from a version not including this patch to one that does, the pluginreg.dat file is re-built.

That will ensure that non-conforming plug-ins don't work with the new version so we don't have this flaky the same plug-ins work for some people and not others with exactly the same browser situation.

Comment 6

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #5)

I think that would be overkill.  Recently there've been lots of other
changes to the plugins interface that might also have caused problems.
We were just better at testing them :-)

Yes, we goofed up.  But I certainly will try hard not to make this
mistake again (i.e. in future plugin tests I'll always remove
pluginreg.dat first).

Let's not make the cure worse than the disease.

Comment 7

[Josh Aas]

backed out

http://hg.mozilla.org/mozilla-central/rev/f6dde14a5ed2

Comment 8

[Steven Michaud [:smichaud] (Retired)]

I've just released a new version of the JEP that has MIME-type
information in its Info.plist file, and won't break with this patch.
See bug 488746.

Comment 9

[Stuart Morgan]

I've been building a list of as many Mac plugins as possible, and I've been checking which still don't use the plist declarations. The list I'm aware of at this point:
 Flash 10.0 (but not 10.1)
 Unity3D
 VLC
 Shockwave

Comment 10

[Josh Aas]

Probably can't do this for a while, too many plugins still depend on a rsrc file.

Comment 11

[Stuart Morgan]

Since this came up recently, an updated list based on what I know now:
- VLC and Veetle
- WebEx
- DjVu
(Shockwave and Unity both updated a while ago.)

All of these are also QD+Carbon, so they are legacy all around.

Comment 12

[Josh Aas]

Attachment: fix v1.1

Comment 13

[Steven Michaud [:smichaud] (Retired)]

I've been testing this patch, and will continue to do so for the rest
of today.

I haven't found any major problems, but I did notice something odd:

There are two (well actually three) downloads for the current version
(11.5.9.620) of the Adobe Shockwave plugin (aka Shockwave Director) --
a "slim" 32-bit download (which is the default), a "full" 32-bit
download and a "full" "64-bit" download.

The "32-bit" plugin doesn't work out-of-process, even in 32-bit mode,
even in FF 3.6.16 or 4.0.  It's a Cocoa app (judging by the symbols it
imports, and the libraries it links in), and its binary has support
for ppc, i386 and x86_64 modes.  But it also has a resource file, and
its Info.plist doesn't include any MIME-type information.

The "64-bit" plugin is in fact a thin i386 binary, though it's also a
Cocoa app.  But it does include MIME-type information in its
Info.plist file, and does work out-of-process (with FF running in
32-bit or 64-bit mode).  (Though it also includes a resource file.)

We need to add a relnote to tell people to download the so-called
"64-bit" Shockwave plugin on FF 4.0 and above -- and not accept the
default download.

Comment 14

[Steven Michaud [:smichaud] (Retired)]

Here's the Shockwave example I tested with:
http://www.forgefx.com/casestudies/prenticehall/ph/waves/waves.htm

Comment 15

[Steven Michaud [:smichaud] (Retired)]

Another bizarre footnote, but still no serious problems:

You need to test with the latest version of the Silverlight plugin
(4.0.60129.0), which uses Cocoa event mode if it detects that it's
running in Firefox -- and can therefore be run out-of-process.  But
the method Silverlight uses to detect that it's running in Firefox is
very fragile -- it sniffs the user-agent string, and gets confused by
the user-agent string used by recent trunk nightlies.

So before testing with Silverlight you need to reset the user-agent
string to something Silverlight knows -- for example FF 4.0's
user-agent string.  See bug 619217 comment #12 for how to do this.

Comment 16

[Steven Michaud [:smichaud] (Retired)]

By the way, this patch works fine with the current version of Silverlight in Carbon event mode -- as long as Silverlight isn't running out-of-process.

Comment 17

[Steven Michaud [:smichaud] (Retired)]

Comment on attachment 527630 [details] [diff] [review]
fix v1.1

I tested this patch on OS X 10.6, in 32-bit mode and 64-bit mode, with
the following plugins, and didn't have any problems (besides the ones
I already described in comment #13 and comment #15):

Java Plugin2 (the current version from Software Update)
QuickTime (the current version from Software Update)
Flash 10.2.159.1 (the current version from Adobe)
Flip4Mac 2.3.8.1 (current version from Telestream)
Shockwave Director 11.5.9.620 (current "64-bit" version from Adobe)
Silverlight 4.0.60129.0 (the current version from Microsoft)

Yes, I remembered to periodically delete the pluginreg.dat file :-)

I also tested with the current version of the WebEx plugin (following
the procedure from bug 622830 comment #0 and bug 622830 comment #6),
and confirmed that this patch breaks it even in 32-bit mode.

Is it time to break old Carbon- and QD-based plugins like WebEx?  I
don't know.  But if we don't backport this patch to older branches,
maybe we can get away with it.

Aside from this I find no technical problems with the patch, so I'll
r+ it.

Comment 18

[Josh Aas]

I am not planning to backport this. The earliest release that would have it would be Firefox 6.

Comment 19

[Stuart Morgan]

(In reply to comment #13)
> There are two (well actually three) downloads for the current version
> (11.5.9.620) of the Adobe Shockwave plugin (aka Shockwave Director) --
> a "slim" 32-bit download (which is the default), a "full" 32-bit
> download and a "full" "64-bit" download.

FWIW, I've already complained to Adobe about this. As far as I can tell, "32-bit" and "64-bit" refer to the modes of Safari they are designed to support; I've explained that this naming scheme is really confusing, and in fact that having two binaries at all should not be necessary, and will cause a lot of user confusion.

Comment 20

[Josh Aas]

pushed to mozilla-central

http://hg.mozilla.org/mozilla-central/rev/da0065d6a53f