299696 - Browser can't instantiate universal-binary or i386 XPCOM/OJI plugins

Status: RESOLVED DUPLICATE of bug 297600

(Core Graveyard :: Plug-ins, defect)

Description

[Steven Michaud [:smichaud] (Retired)]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.8) Gecko/20050511
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.8) Gecko/20050511

On OS X, none of the Mozilla family of browsers can load an XPCOM or
OJI plugin that's a "universal binary" (aka a "fat binary" for the ppc
and i386 architectures).

nsPluginHostImpl::GetPluginFactory() (in modules/plugin/base/src/
nsPluginHostImpl.cpp) looks for an "NSGetFactory" symbol in each
(potential) plugin.  If it finds one and the (potential) plugin's
binary checks out OK via IsCompatibleExecutable(), GetPluginFactory()
assumes that it's found an XPCOM plugin and calls its NSGetFactory
entry point.

IsCompatibleExecutable() is a no-op on all platforms but "XP_MACOSX".
But on Mac OS X it checks the "signature" in the binary's first eight
bytes.  IsCompatibleExecutable() needs to reject everything but a
MACH-O bundle.  The signature for a single-architecture MACH-O bundle
is "0xfeedface" (though the order of the digits is different on
big-endian (ppc) and little-endian (i386) architectures).  But the
signature for a "universal binary" (more properly a "Next MAB" file)
is "0xcafebabe".  (Yes, Java class files also have this signature
... but that's another story.)

As currently written, IsCompatibleExecutable() rejects all universal
binaries.  And because it assumes the signature's order is big-endian,
it also rejects single-architecture i386 binaries.



Reproducible: Always

Comment 1

[Steven Michaud [:smichaud] (Retired)]

Attachment: Patch to fix this problem

I haven't yet tested this patch, but it (or something like it) should
solve the problem.  The patch is against the current CVS version of
nsPluginHostImpl.cpp.

Comment 2

[Mark Mentovai]

Wow, thanks.  I'm duping this to 297600 because it was filed first and has a
similar patch.  If you've got any more ideas on this issue, feel free to
scribble them over there.

*** This bug has been marked as a duplicate of 297600 ***

Comment 3

[Steven Michaud [:smichaud] (Retired)]

This bug (299696) isn't a duplicate of bug 297600 (though the two are
related) -- this bug is actually a separate (and more urgent) problem.

But it looks like both bugs need a single solution, so I'm happy
enough to continue discussion of this bug (if need be) at bug 297600.

Comment 4

[Steven Michaud [:smichaud] (Retired)]

I've changed the description to describe this problem more precisely.

The browser can and does _load_ universal-binary and i386 XPCOM
plugins (open_executable() does this).  But (because it doesn't call
NSGetFactory) it doesn't _instantiate_ them.

Comment 5

[Steven Michaud [:smichaud] (Retired)]

Attachment: Revised patch that conforms to patch from bug 297600

This patch "borrows" code from the relevant part of the (current) bug
297600 patch (https://bugzilla.mozilla.org/attachment.cgi?id=186349).
Though it's functionally equivalent, it's cleaner than my original
patch.