134448 - XPTI needs to account for the system wide plugins folder on OSX

Status: VERIFIED FIXED

(Core Graveyard :: Embedding: Mac, defect, P2)

Description

[Arun Ranganathan]

Currently, the only way to expose your plugin (Shared Library) to scripting is
via XPT files (e.g. see the write-up on
http://mozilla.org/projects/plugins/scripting-plugins.html).  In addition to
dropping your Shared Library into the Mac system-wide plugins folder, XPT files
ought to also be dropped there and should work out of the box when embedded
Netscape Gecko clients *or* Mozilla 1.0-era clients start up on Mac OSX.  I
couldn't find a similar bug, so I've logged this.  If logged in error, please
close this out.

Comment 1

[Arun Ranganathan]

Adding others to the CC list; adding topembed keyword.

Comment 2

[Conrad Carlen (not reading bugmail)]

  I don't think scriptable shared library plugins should be installed in
~/Library/Internet Plug-Ins or /Library/Internet Plug-Ins. Both of those folders
are defined by the system and are to be used by *any* program supporting
internet plugins, not just mozilla. The types of files you're talking about are
only of use to mozilla and would only slow down or confuse other apps scanning
this folder for plugins.
  What I'd rather do is provide a location in the user domain as well as all
users: ~/Library/Mozilla/Plug-Ins and /Library/Mozilla/Plug-Ins.
  Or, only ~/Library/Mozilla/Plug-Ins because if the user has admin priveleges,
they could install into the Plug-Ins in the app folder.

Comment 3

[Conrad Carlen (not reading bugmail)]

> Or, only ~/Library/Mozilla/Plug-Ins because if the user has admin priveleges,
they could install into the Plug-Ins in the app folder.

BTW, this is what Unix and Windows do. Simple enough to make the Mac behave th
same way.

Comment 4

[Peter Lubczynski]

Attachment: ScriptablePluginTestcase.sit

I confirm the scripting with the xpt file in the ~/Library/Internet Plug-ins
folder does not work. Here's a simple scriptable OSX plugin testcase.

Comment 5

[Conrad Carlen (not reading bugmail)]

> I confirm the scripting with the xpt file in the ~/Library/Internet Plug-ins
folder does not work.

Yeah, I know that and why: it's not being scanned by xpti. My point is, we
should not scan there but instead a mozilla-specific location.

Comment 6

[Steve Dagley]

I agree w/ccarlen.  The systemwide 'Internet plug-ins' folder is for plugins
that can in fact be used systemwide.  Shared libraries w/XPT files that can only
be used by Mozilla rather than a generalized plugins ('BRPL' files) don't belong
there.

Comment 7

[Peter Lubczynski]

So a plugin installer will need to search the entire filesystem for the
locations of Gecko based browser to find the components or plug-ins local folder
to drop the XPT? Can we give the XPT files a special type?

Comment 8

[Patrick C. Beard]

In comment #2, Conrad Carlen wrote:
>I don't think scriptable shared library plugins should be
>installed in ~/Library/Internet Plug-Ins or /Library/Internet
>Plug-Ins. Both of those folders are defined by the system and are
>to be used by *any* program supporting internet plugins, not just
>mozilla. The types of files you're talking about are only of use
>to mozilla and would only slow down or confuse other apps scanning
>this folder for plugins. What I'd rather do is provide a location
>in the user domain as well as all users:
>~/Library/Mozilla/Plug-Ins and /Library/Mozilla/Plug-Ins. Or, only
>~/Library/Mozilla/Plug-Ins because if the user has admin
>priveleges, they could install into the Plug-Ins in the app folder.

I definitely think we should support all of those locations for
plugin scanning, but I don't agree that scriptable plugins should
be banned from the global internet plugins folder. After all,
there are some browsers on Mac OS X that are supporting a
companion Java .class file for scripting plugins (OmniWeb) which
we won't support. I can envision a plugin developer wanting to be
scriptable both using .class files and .xpt files, so it is
reasonable to expect that such a plugin would be scriptable when
placed in the global internet plugins folder.

Comment 9

[Steve Dagley]

If it's a scriptable plugin that other apps can use, but not necessarily the
XPCOM scriptable part, then I see no problem with putting the plugin and the
.xpt file into the 'Internet plug-ins' folder.  The reference to 'Shared
Library' is what caught my attention and what I was objecting to as I thought it
referred to the 'newfangled' Netscape only plugin architecture.  I blame Arun
for using bad terminology :-)

Comment 10

[Arun Ranganathan]

sdagley's right, I used some bad terminology and paraded my ignorance of Mac OS,
but the bottom line is that RealNetworks could greatly benefit from this,
because they are a scriptable plugin on Mac (RealPlayer 8 and RealOne).  Rather
than having them pound each Gecko-based application, determine the Components
directory, and slap an XPT in each Components directory, it would be much easier
to put the XPT file in one place for any future Gecko-based client to find it.
Of course, existing Gecko-based clients require rigorous application enumeration
(e.g. N6.1, N6.2) but the future is bright if this lands.  How can it get a "+"
for future Netscape-branded releases?

Comment 11

[Conrad Carlen (not reading bugmail)]

OK. Currently, xpti scans in the list of dirs returned by
NS_APP_PLUGINS_DIR_LIST. nsPluginHostImpl scans that list and in the list of
dirs returned by NS_OS_PLUGINS_DIR_LIST. That list includes (on OSX)
~/Library/Internet Plug-Ins and /Library/Internet Plug-Ins.

How about this: We just put the dirs from the "OS" list into the "APP" list. The
"OS" list is always empty on any platform except Mac since it's the only OS that
really supports OS-defined plugin locations. Since embeddors can define the
"APP" list, they're not affected in terms of control. And, it's one simple
movement of code in XPCOM - no change to consumers.

If xpti is scanning in global, OS-defined plugin dirs which may contain random
plugin files that are not xpti files, it might cause problems - depends on how
robust its file identification checks are.

Comment 12

[Peter Lubczynski]

Yeah, I like moving everything to one directory service provider.

Comment 13

[Conrad Carlen (not reading bugmail)]

Attachment: proposed fix #1

A simple 1-liner which causes xpti iface manager to scan OS-defined plug-in
dirs.

Comment 14

[Conrad Carlen (not reading bugmail)]

Attachment: proposed fix #2

Requires no change to xpti iface manager, moves the OS-defined locations in
NS_APP_PLUGINS_DIR_LIST.

Comment 15

[Conrad Carlen (not reading bugmail)]

Can I get r= by peterlubczynski, sr= by beard? Also, jband, can you take a look?
  
  There are 2 independent patches. Deciding which one to use is the first
question. The larger patch just moves the locations in NS_OS_PLUGIN_DIR_LIST
into NS_APP_PLUGIN_DIR_LIST. The "OS" list is only supported on Mac and I think
it's cleaner to have this in the "APP" list. Being in the "APP" list, it's
possible for an embeddor to override as well.
  I'm away until 7/3. If this needs to go in before I'm back, somebody feel free
to go with either patch and check it in assuming it's reviewed without problems.

Comment 16

[Conrad Carlen (not reading bugmail)]

> I'm away until 7/3

Whoops, make that 6/3

Comment 17

[Patrick C. Beard]

Comment on attachment 84306 [details] [diff] [review]
proposed fix #2

sr=beard, nit I prefer explicit testing of the result of calls to OSErr
returning functions to noErr rather than using the ! operator.

Comment 18

[Peter Lubczynski]

Comment on attachment 84306 [details] [diff] [review]
proposed fix #2

r=peterl

should NS_OS_PLUGINS_DIR_LIST be removed completely since it's not being used
anymore?

Comment 19

[Conrad Carlen (not reading bugmail)]

Fixed. I kept NS_OS_PLUGINS_DIR_LIST defined. I've objected to freezing
nsAppDirectoryServiceDefs.h because we should always be able to add new keys -
as long as existing keys are preserved.

Once verified with the test case supplied here, let's get this onto the branch.

Comment 20

[Peter Lubczynski]

nominating

Comment 21

[Jaime Rodriguez, Jr.]

shrir - can you pls verify this on the trunk? thanks!

Comment 22

[shrirang khanzode]

verified on OS x trunk 0625. Scripting works from system IP folder..Users/IP 
folder, components folder and Plugins folder. XPTI.DAT lists the xpt file (flash 
) just fine for all these locations and scripting works. Tested using scriptable 
flash.

Comment 23

[shrirang khanzode]

The only thing that seemed incorrect was this:

After I copied over the flashplayer.xpt to my local 'plugins' folder 
or'components', restarting the browser did not list the xpt file in xpti.dat. I 
had to remove the earlier version od xpti.dat and then restart the browser- 
forcing a new xpti.dat which picked up the file just. This issue did not arise 
when I manually copied the xpt to Systems/IP folder and user/IP folder. Also,

Comment 24

[Jaime Rodriguez, Jr.]

adt1.0.1+ (on ADT's behalf) approval for checkin to the 1.0 branch. pls check
this in asap, then add the "fixed1.0.1" keyword.

Comment 25

[Peter Lubczynski]

I verify this is fixed on the trunk with Classic and Carbon builds.

However, I found a another serious, unrelated problem described in bug 154272.

The problem is that we don't always detect at startup when new XPT file so users
will be VERY confused that scripting is not working.

Comment 26

[Judson Valeski]

please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+"
keyword and add the "fixed1.0.1" keyword.

Comment 27

[Conrad Carlen (not reading bugmail)]

Checked into branch.

Comment 28

[shrirang khanzode]

verif on branch 0718.

Comment 29

[Dave Yost]

On Mac OS 10.2.6/QuickTime 6.3, I installed Netscape 7.1 and Mozilla 1.5a.

QuickTime scripting does not work in either browser.

Should be reopened.

Comment 30

[Dave Yost]

Hmmm...  A while back I the shell script workaround below.  Now it changes what it sets out to 
change, but it doesn't make Netscape able to do QuickTime scripting.

cat << 'XoXoX' | sudo sh -x
NETSCAPE_APP=/Local/Software/Netscape/Netscape.app
cp -p /Library/Internet\ Plug-ins/nsIQTScriptablePlugin.xpt "$NETSCAPE_APP/Contents/MacOS/
components"
rm "$NETSCAPE_APP/Contents/MacOS/components/xpti.dat"
open "$NETSCAPE_APP"
XoXoX

I also tried moving the xpt file to /Library/Mozilla/Plug-Ins/ and /Library/Mozilla/

RealOne has problems, too.  The RealOne embedded UI does not work in either browser (tho it 
does work in Safari).  Try
http://www.bbc.co.uk/radio/aod/radio3.shtml

(There are also serious rendering problems on this page, even worse if you resize it.)

Comment 31

[Steve Dagley]

This bug does not need to be re-opened.  The problem is that the ABI for
scriptable plugins mush match between the plugin and the browser.  Now that
Mozilla is being built as a Mach-O app plugins need to be re-built as Mach-O. 
They also need to use the new selector for the Mach-O scriptable interface which
was changed so we wouldn't crash trying to use a scriptable CFM plugin.

The one evang bug I found logged on this is #203861