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.
Created attachment 352164 [details] [diff] [review]
Comment on attachment 352164 [details] [diff] [review]
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)
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)
4) Real Player 11.0
Movie trailers at http://www.film.com/movies/trailers
5) Flip4Mac 220.127.116.11
Examples at http://www.windowsmedia.com/MediaGuide/Home
pushed to mozilla-central
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.
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.
(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
Let's not make the cure worse than the disease.
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.
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)
Probably can't do this for a while, too many plugins still depend on a rsrc file.
Since this came up recently, an updated list based on what I know now:
- VLC and Veetle
(Shockwave and Unity both updated a while ago.)
All of these are also QD+Carbon, so they are legacy all around.
Created attachment 527630 [details] [diff] [review]
I've been testing this patch, and will continue to do so for the rest
I haven't found any major problems, but I did notice something odd:
There are two (well actually three) downloads for the current version
(18.104.22.1680) 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
Here's the Shockwave example I tested with:
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.
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 on attachment 527630 [details] [diff] [review]
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 22.214.171.124 (current version from Telestream)
Shockwave Director 126.96.36.1990 (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
I am not planning to backport this. The earliest release that would have it would be Firefox 6.
(In reply to comment #13)
> There are two (well actually three) downloads for the current version
> (188.8.131.520) 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.
pushed to mozilla-central