339238 - Java doesn't work when MRJPlugin.plugin is a symbolic link

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Mark Mentovai]

When MRJPlugin.plugin is a symbolic link to some far-off location, as is the case in the tree built at objdir/dist prior to packaging, Java doesn't work.  MRJPlugin loads and begins executing, as evidenced by these messages on stdout (which, as indicators of success, probably aren't necessary):

### MRJPlugin:  getPluginBundle() here. ###
### MRJPlugin:  CFBundleGetBundleWithIdentifier() succeeded. ###
### MRJPlugin:  CFURLGetFSRef() succeeded. ###

but Java is not functional.  This is almost certainly the result of MRJPlugin's use of FSSpec to build its classpath and find resources.

This makes testing Java from the build tree a real pain.

Comment 1

[Steven Michaud [:smichaud] (Retired)]

Mark, how would you suggest I fix this problem?

(For the moment I'm just assuming your report is correct -- I haven't
yet done any tests of my own.)

Comment 2

[Steven Michaud [:smichaud] (Retired)]

Another observation:

The MRJ Plugin JEP looks first for JavaEmbeddingPlugin.bundle in the
directory where it (MRJPlugin.bundle) is located, then in
~/Library/Internet Plug-Ins/, then in /Library/Internet Plugin-Ins.  I
probably shouldn't change this.

Have you tried putting a soft link to JavaEmbeddingPlugin.bundle in
the same directory where the MRJPlugin.bundle (the original) is
located?

Comment 3

[Steven Michaud [:smichaud] (Retired)]

> Have you tried putting a soft link to JavaEmbeddingPlugin.bundle in
> the same directory where the MRJPlugin.bundle (the original) is
> located?

Here's a better question:

Have you tried putting either the original JavaEmbeddingPlugin.bundle
or a soft link to it in the same directory where the MRJPlugin.bundle
(the original) is located?

Comment 4

[Mark Mentovai]

Steven, the bug is not in loading JavaEmbeddingPlugin.bundle.  I should have been more clear.  When MRJPlugin.plugin is NOT a symlink and JavaEmbeddingPlugin.bundle is a symlink, Java functions properly.  The problem only occurs when MRJPlugin.plugin itself is a symlink, regardless of how JavaEmbeddingPlugin.bundle is installed.  For these tests, I don't have the .plugin or .bundle anywhere else on my system other than in the app's own plugins directory.

(That should resolve your questions about placement, but just for the record, when these guys are symlinks, the symlinks both point to the same directory:

lrwxrwxrwx   1 mark  mark   85 May 25 14:06 JavaEmbeddingPlugin.bundle -> /Users/mark/lizard/1.8/build/firefox-shared/plugin/oji/JEP/JavaEmbeddingPlugin.bundle
lrwxrwxrwx   1 mark  mark   75 May 25 14:06 MRJPlugin.plugin -> /Users/mark/lizard/1.8/build/firefox-shared/plugin/oji/JEP/MRJPlugin.plugin

Anyway...

As I said, I've got a strong suspicion that this is due to the use of FSSpec, which comes from a time before the Mac went all Unixy and got symlinks.  This is probably very similar to bug 335166, where we saw exactly the same sort of failure when running from a build tree when an FSSpec was being used to refer to something that was a symbolic link.  As you can see from the patch there, I fixed the problem by getting rid of FSSpec entirely and using more modern APIs to locate the target file.

If you don't have time to look at this, I wouldn't mind poking in, I just wanted to make sure you were aware of it before releasing 0.9.5+e.  Now that you're aware, feel free to release anyway if you're ready and don't think an immediate fix is warranted.  (But you'll probably want to wait until the trunk badness has settled down anyway...)

Comment 5

[Steven Michaud [:smichaud] (Retired)]

Thanks for the extra information.  I currently suspect that
MRJPlugin.plugin is failing to figure out where it's being run from
(very likely for the reasons that you've given).

If the fix is easy, I'll include it in JEP 0.9.5+e.

Comment 6

[Steven Michaud [:smichaud] (Retired)]

This is a browser bug!

It never calls the NSGetFactory() entry point in MRJPlugin.cpp.

Also, as far as I can tell the FSSpec that gets created in
MRJPlugin.cpp's getPluginBundle() (thePluginSpec) does follow soft
links correctly.  And in any case JavaEmbeddingPlugin.bundle does get
loaded.

Comment 7

[Mark Mentovai]

Aha!  I'll investigate from this side then!

Comment 8

[Mark Mentovai]

Attachment: Patch

The check that was failing was the IsCompatibleExecutable test.

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/plugin/base/src/nsPluginHostImpl.cpp&rev=1.555&mark=4540,4542,4547-4548#4535

The reason for the failure is explained in the patch.

Comment 9

[Darin Fisher]

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

>Index: mozilla/modules/plugin/base/src/nsPluginHostImpl.cpp

>+  if (::stat(path, &sb) == 0 && S_ISDIR(sb.st_mode))
>+    return PR_TRUE;
>+  return PR_FALSE;

It looks like you can eliminate the branch:

    return ::stat(path, &sb) == 0 && S_ISDIR(sb.st_mode);


>+  if (::lstat(path, &sb) == 0 && S_ISLNK(sb.st_mode))
>     return PR_TRUE;
>   return PR_FALSE;

ditto


sr=darin

Comment 10

[Mark Mentovai]

Checked in on the trunk with that change.

Comment 11

[Mark Mentovai]

Attachment: As checked in

No risk, eases development, setting a1.8.1? on myself as a reminder.

Comment 12

[Mark Mentovai]

Comment on attachment 223460 [details] [diff] [review]
As checked in

Checked in on MOZILLA_1_8_BRANCH.