305098 - JEP only built for camino + firefox

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Benjamin Smedberg]

Bug 303161 made the JEP java embedding plugin only build for Firefox + Camino.
This seems very silly: if JEP is part of our core plugin architecture on mac
(and it seems like it should be), then it should be built whenever we enable
plugins, not just for Firefox + Camino.

Comment 1

[Josh Aas]

At the moment JEP is more of a test than "part of our core plugin architecure".
However, so long as no project owners are getting JEP when they don't want it,
this sounds fine.

Comment 2

[Mark Mentovai]

CCing project owners.  How do y'all feel about bundling the JEP for Mac OS X? 
More background is in bug 303161 and http://javaplugin.sourceforge.net/ .

Comment 3

[Robert Kaiser]

IMHO, it should be built unconditional of the application, i.e. the ifneq in
http://lxr.mozilla.org/seamonkey/source/Makefile.in#341 should just be removed.

Comment 4

[Mark Mentovai]

Attachment: Patch

Enable JEP whenever MOZ_PLUGINS is defined.  Logic is moved out of the root
makefile and into JEP's.

Comment 5

[Mark Mentovai]

Comment on attachment 193085 [details] [diff] [review]
Patch

The dependent patch did land on the 1.8 branch.  I'm not sure if anyone wants
to take this there - it's more up to the consensus of the project owners - but
it's not really my decision to make.  Nominating for approval so the decision
can be made.

This patch bundles the Mac JEP plugin in any product whenever plugins are
enabled.  Without this patch, the JEP plugin is only bundled with Camino (bug
301076) and Firefox (bug 303161).

Comment 6

[Benjamin Smedberg]

We absolutely need to bundle JEP with xulrunner and the suite if we're bundling
it with ffox/camino. What other projects are there (I'm presuming that tbird
still disables plugins, right?)

Comment 7

[Mark Mentovai]

I have MOZ_PLUGINS=1 in a standard Thunderbird build.  I'd like to hear from
mscott on this.

Comment 8

[Dan Mosedale (:dmosedale, :dmose)]

I believe TBird still does disable plugins.  One possible use case for at least
some plugins would be to allow TBird to view (eg) .doc and .pdf files inline. 
Other plugins (eg Flash and possibly Java) seem less desirable.

I can imagine similar uses cases for plugins in Sunbird as the ones I mentioned
above for TBird (eg attaching an agenda.doc to an event).  However, I kinda
suspect that this is rarer in email.

Comment 9

[Benjamin Smedberg]

Does tbird only pref-off plugins? That makes more sense, and if it does, then we
should still be building JEP (I presume that JEP honors the disable-plugins
prefs like any other plugin).

Comment 10

[Benjamin Smedberg]

http://lxr.mozilla.org/mozilla/source/mail/app/profile/all-thunderbird.js#180

Comment 11

[Steven Michaud [:smichaud] (Retired)]

> I presume that JEP honors the disable-plugins prefs like any other plugin

As far as I know it's the plugin host itself (e.g. the browser) that checks
this setting, and loads or doesn't load plugins accordingly.

In any case, there is (as far as I know) no logic in the MRJ Plugin JEP that
checks this setting.  (The MRJ Plugin JEP is what's loaded by Mozilla-family
plugin hosts.  It in turn loads JavaEmbeddingPlugin.bundle (which enables
support for Java versions higher than 1.3.1) if that's available.)

Comment 12

[Benjamin Smedberg]

That's what I figured. We should test this to make sure, of course.

Comment 13

[Mark Mentovai]

(In reply to comment #11)
> In any case, there is (as far as I know) no logic in the MRJ Plugin JEP that
> checks this setting.  (The MRJ Plugin JEP is what's loaded by Mozilla-family
> plugin hosts.  It in turn loads JavaEmbeddingPlugin.bundle (which enables
> support for Java versions higher than 1.3.1) if that's available.)

Steven, as long as we've got your attention: one thing that concerns me is what
you say (or imply) about mtime checking in the JEP readme.  We obviously want
the MRJ plugin to load JEP, but it sounds like that's not guaranteed.  I don't
mind loading newer JEPs installed elsewhere in the system, but I'm a little
frightened of the inconsistent results we'd see if and when Apple bumps the
mtime on the 1.3 plugin.  Am I worrying for nothing, or is this something we can
take proactive control of?

Comment 14

[Steven Michaud [:smichaud] (Retired)]

> Steven, as long as we've got your attention: one thing that concerns me is
> what you say (or imply) about mtime checking in the JEP readme.

This isn't something you have to worry about if MRJPlugin.plugin and
JavaEmbeddingPlugin.bundle are in the distro's Contents/MacOS/plugins
directory.  That's where the browser looks first for plugins to handle a given
MIME type.  Once it finds one it doesn't look any further.

(You only have to fiddle with MRJPlugin.plugin's last modification time if you
install it (and JavaEmbeddingPlugin.bundle) to a directory that might contain
another plugin that handles the x-java-applet or x-java-vm MIME types -- such
as /Library/Internet Plug-Ins/ or ~/Library/Internet Plug-Ins/.  Whenever the
browser checks a directory for plugins, it examines them in the order of their
most recent modification, newest first.  The relevant code is in
nsPluginHostImpl.cpp.  The plugins in a given directory are sorted by mtime
using a call to pluginFilesArray.Sort() in ScanPluginsDirectory().

I assume a non-browser plugin host would behave the same way.)

Comment 15

[Mark Mentovai]

(In reply to comment #14)
> This isn't something you have to worry about if MRJPlugin.plugin and
> JavaEmbeddingPlugin.bundle are in the distro's Contents/MacOS/plugins
> directory.  That's where the browser looks first for plugins to handle a given
> MIME type.  Once it finds one it doesn't look any further.

That I understand - I was more worried about the MRJ plugin finding an outdated
JEP bundle or not finding the JEP bundle at all.  I've taken a look at the MRJ
source and see that this is impossible (getJEPBundle), so it's nothing to worry
about.  This is clear again now that I've reread your README, which mentions
nothing of the bundle's mtime.  Thanks so much for your work on this plugin!

Comment 16

[Steven Michaud [:smichaud] (Retired)]

> I don't mind loading newer JEPs installed elsewhere in the system

If both MRJPlugin.plugin and JavaEmbeddingPlugin.bundle are in the distro's
Contents/MacOS/plugins directory, and if their versions match,
MRJPlugin.plugin will always load the "right" JavaEmbeddingPlugin.bundle.

For a long time the MRJ Plugin JEP has been written not to load a
JavaEmbeddingPlugin.bundle whose version doesn't match its own.  For an
equally long time I've bumped the version for both files when I issue a new
release (even a new "nightly").  This "version number" is internal, and known
only to the MRJ Plugin JEP and JavaEmbeddingPlugin.bundle.  It's not any of
the version numbers in Info.plist or InfoPlist.strings, or what you see when
you do Get Info (though I've been careful to keep these "public" version
numbers in sync with the "internal" ones).

As of JEP 0.9.3, the MRJ Plugin JEP looks for a JavaEmbeddingPlugin.bundle in
the following directories, in the following order -- the directory from which
it's been run, ~/Library/Internet Plug-Ins, /Library/Internet Plug-Ins.  (It
used only to look in ~/Library/Internet Plug-Ins and /Library/Internet
Plug-Ins.  My change was intended to make it possible to achieve a
bullet-proof solution to the versioning problem (and to the mtime problem) by
putting both files in the distro's Contents/MacOS/plugins directory.)

My comment was written before your own latest one.  But since I went to the
trouble ... :-)

Comment 17

[Mark Mentovai]

Mail has plugins preffed off and calendar is built without plugin support:

http://lxr.mozilla.org/mozilla/source/calendar/sunbird/config/mozconfig#22

so I've checked this in on the trunk.  It's a good idea on the branch too, for
consistent Java support across all 1.8-based products.  This primarily affects
Seamonkey and XULRunner.

Comment 18

[Mark Mentovai]

Requesting blocking1.8b4 for additional 1.8 driver attention.

Comment 19

[Steven Michaud [:smichaud] (Retired)]

One last tidbit:

> As of JEP 0.9.3, the MRJ Plugin JEP looks for a JavaEmbeddingPlugin.bundle
> in the following directories, in the following order -- the directory from
> which it's been run, ~/Library/Internet Plug-Ins, /Library/Internet
> Plug-Ins.

This is slightly incorrect.  Version 0.9.3 of the MRJ Plugin JEP actually
looks in the directory from which it's been run, _the directory above that_,
~/Library/Internet Plug-Ins, and /Library/Internet Plug-Ins.

I did this because I had trouble getting an older version of Camino (I can no
longer remember which one) to deal with having a non-recognized plugin type
(i.e. JavaEmbeddingPlugin.bundle) in its Contents/MacOS/plugins directory.

Comment 20

[Mark Mentovai]

See comment 6 - JEP is already bundled with Firefox and Camino on the branch,
and according to that comment, absolutely must be bundled the same way on the trunk.

Comment 21

[Mark Mentovai]

Fixed on 1.8.