Last Comment Bug 468678 - remove support for resource (.rsrc) files in Mac OS X plugins
: remove support for resource (.rsrc) files in Mac OS X plugins
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: Trunk
: x86 Mac OS X
: -- normal (vote)
: ---
Assigned To: Josh Aas
: Benjamin Smedberg [:bsmedberg]
Depends on: 469510
  Show dependency treegraph
Reported: 2008-12-09 11:44 PST by Josh Aas
Modified: 2011-04-28 16:59 PDT (History)
6 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

fix v1.0 (11.80 KB, patch)
2008-12-09 11:58 PST, Josh Aas
smichaud: review+
roc: superreview+
Details | Diff | Splinter Review
fix v1.1 (11.35 KB, patch)
2011-04-21 13:02 PDT, Josh Aas
smichaud: review+
Details | Diff | Splinter Review

Description User image Josh Aas 2008-12-09 11:44:34 PST
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 User image Josh Aas 2008-12-09 11:58:28 PST
Created attachment 352164 [details] [diff] [review]
fix v1.0
Comment 2 User image Steven Michaud [:smichaud] (Retired) 2008-12-11 08:04:28 PST
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)

2) QuickTime 7.5.5 (installed by Apple)

   Movie trailers at

3) Silverlight 1.0 (last version to support PPC)

4) Real Player 11.0

   Movie trailers at

5) Flip4Mac

   Examples at
Comment 3 User image Josh Aas 2008-12-11 14:01:17 PST
pushed to mozilla-central
Comment 4 User image Steven Michaud [:smichaud] (Retired) 2008-12-13 18:34:23 PST
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 User image Bill Gianopoulos [:WG9s] 2008-12-14 11:22:55 PST
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 User image Steven Michaud [:smichaud] (Retired) 2008-12-15 07:48:54 PST
(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 User image Josh Aas 2008-12-15 09:29:06 PST
backed out
Comment 8 User image Steven Michaud [:smichaud] (Retired) 2009-04-16 13:30:12 PDT
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 User image Stuart Morgan 2010-04-17 06:36:30 PDT
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)
Comment 10 User image Josh Aas 2010-06-01 22:25:09 PDT
Probably can't do this for a while, too many plugins still depend on a rsrc file.
Comment 11 User image Stuart Morgan 2011-03-02 15:26:01 PST
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 User image Josh Aas 2011-04-21 13:02:45 PDT
Created attachment 527630 [details] [diff] [review]
fix v1.1
Comment 13 User image Steven Michaud [:smichaud] (Retired) 2011-04-25 14:04:42 PDT
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
( 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 User image Steven Michaud [:smichaud] (Retired) 2011-04-25 14:14:50 PDT
Here's the Shockwave example I tested with:
Comment 15 User image Steven Michaud [:smichaud] (Retired) 2011-04-25 14:37:13 PDT
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 User image Steven Michaud [:smichaud] (Retired) 2011-04-25 15:02:06 PDT
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 User image Steven Michaud [:smichaud] (Retired) 2011-04-25 15:43:54 PDT
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 (the current version from Adobe)
Flip4Mac (current version from Telestream)
Shockwave Director (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 User image Josh Aas 2011-04-25 19:25:20 PDT
I am not planning to backport this. The earliest release that would have it would be Firefox 6.
Comment 19 User image Stuart Morgan 2011-04-25 20:57:43 PDT
(In reply to comment #13)
> There are two (well actually three) downloads for the current version
> ( 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 User image Josh Aas 2011-04-28 16:59:58 PDT
pushed to mozilla-central

Note You need to log in before you can comment on or make changes to this bug.