353160 - 1.5.0.7 does not allow text to be entered in "password" field of Java applet

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Derek Merrifield]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/418.8 (KHTML, like Gecko) Safari/419.3
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O;

MAC OS X 10.4.7, iMAC 1.8GHz, PPC G5 17", 512 MB RAM, Firefox 1.5.0.7

Text entered into username field are not recognized, and cannot enter text into password field.

We use Watchguard firewall and require our users to log into the firewall via their java applet.  I was able to log into the Watchguard firewall to download the 1.5.0.7 update using the Watchguard Java applet, but once the update was installed and I restarted Firefox, as the update required, I was no longer able to enter text into the Java applet.

This works on the same iMAC with Safari and I reproduced this on another iMAC PPC G5 and MAC Mini 1.5 GHz Intel Core Solo, 512MB RAM .  Unfortunately, I do not know of another login using a Java applet besides Watchguard's.

Reproducible: Always

Steps to Reproduce:
1. Install 1.5.0.7 update
2. Launch Java applet for Watchguard firewall
3. Enter username (username is entered into the username field)
4. Enter password (no text is entered, cursor never moves)

Actual Results:  
Java applet continues to ask for username, appears that the text entered into the username field is never seen.  No text is allowed to be entered into the password field and the cursor never moves.  

Expected Results:  
Username is entered and password is allowed to be entered, cursor moves and **** are displayed in place of typed text in password field, authentication succeeds.

One note of interest, if I turn on Caps lock and enter a username and tab to the password field it does recognize that Caps lock is on and displays an up arrow at the end of the password field.

Comment 1

[Nick Thomas [:nthomas] (UTC+12)]

Fallout from bug 346156 ?

Comment 2

[Steven Michaud [:smichaud] (Retired)]

> Fallout from bug 346156 ?

I doubt it.

But here's something for the reporter to try:  Derek, does the same
problem happen with Firefox 1.5.0.6, or 1.5.0.5?

Side note:  If this _does_ turn out to be a problem with the Java
Embedding Plugin, I won't be able to do anything about it until I get
either a publicly accessible URL that I can test with, or a test-case
applet that demonstrates the problem.

Comment 3

[Derek Merrifield]

(In reply to comment #2)
> > Fallout from bug 346156 ?
> 
> I doubt it.
> 
> But here's something for the reporter to try:  Derek, does the same
> problem happen with Firefox 1.5.0.6, or 1.5.0.5?
> 
> Side note:  If this _does_ turn out to be a problem with the Java
> Embedding Plugin, I won't be able to do anything about it until I get
> either a publicly accessible URL that I can test with, or a test-case
> applet that demonstrates the problem.
> 

No, Java applet worked fine in 1.5.0.6 and previous versions.  I was using 1.5.0.6 when I authenticated using Java applet to download 1.5.0.7 update.  This worked prior to installing 1.5.0.7.

Derek

Comment 4

[Steven Michaud [:smichaud] (Retired)]

OK.  I still _really_ need either a test-case applet or a publicly
accessible URL that I can test with.  But here's something you can do
in the meantime that might provide useful information:

Run the "Console" app (in Applications : Utilities).  Make sure its
"console log" window is open (if it isn't choose "Open Console Log"
from the File menu).  Click on the "Clear" button to clear the
existing contents of the "console log" window.  Then choose "Open ..."
from the File menu and browse to "Java Console.log" in the
Library/Logs directory under your home directory (i.e. to
~/Library/Logs/Java Console.log).

Now try your "steps to reproduce" from comment #0, and see what shows
up in the "console.log" and "Java Console.log" windows.

If anything interesting appears in either window, choose "Save a copy
as ..." from the File menu to save copies of one or both windows, and
attach them (or it) to this bug using "Create a New Attachment" above.

Comment 5

[Derek Merrifield]

Attachment: Console Log

Comment 6

[Derek Merrifield]

Attachment: Java Console Log

Comment 7

[Derek Merrifield]

Nothing interesting in the Java Console log, but there is in the Console log.

Comment 8

[Steven Michaud [:smichaud] (Retired)]

> but there is in the Console log

Unfortunately not.  I've often seen the
_wrapRunLoopWithAutoreleasePoolHandler error, and it seems to be
completely benign.  I'm also not sure whose "fault" it is.

Please keep an eye out for any publicly accessible Java applet login
dialogs that you have trouble with.

Also (and please bear with me on this), I'd be interested to see what
happens with Firefox 1.5.0.5 or 1.5.0.6 if you try them _now_.

Comment 9

[Steven Michaud [:smichaud] (Retired)]

Actually, there _is_ something potentially interesting in your Java
Console.log.  I notice that the Main applet is at an odd address
(http://10.1.3.10:4100/).  Does this mean that a proxy is involved
somewhere?

Also, do you have any interesting server-side error messages?

Comment 10

[Derek Merrifield]

I have actually uninstalled Firefox on my iMAC and reinstalled Firefox 1.5.0.6.  The Java applet functionality is working as it was before updating to 1.5.0.7, I can authenticate using the Java applet again.  We will have patience on this issue.  We will hold off on upgrading to 1.5.0.7 until this issue can be resolve.  Thanks for you prompt attention.

Derek

(In reply to comment #8)
> > but there is in the Console log
> 
> Unfortunately not.  I've often seen the
> _wrapRunLoopWithAutoreleasePoolHandler error, and it seems to be
> completely benign.  I'm also not sure whose "fault" it is.
> 
> Please keep an eye out for any publicly accessible Java applet login
> dialogs that you have trouble with.
> 
> Also (and please bear with me on this), I'd be interested to see what
> happens with Firefox 1.5.0.5 or 1.5.0.6 if you try them _now_.
> 

Comment 11

[Derek Merrifield]

Port 4100 is the port used by Watchguard's Java applet to authenticate to the Firewall.  We do not run a proxy server on our network, but Watchguard Firewalls do use proxies.  Hope that answers your question adequately.

Derek

(In reply to comment #9)
> Actually, there _is_ something potentially interesting in your Java
> Console.log.  I notice that the Main applet is at an odd address
> (http://10.1.3.10:4100/).  Does this mean that a proxy is involved
> somewhere?
> 
> Also, do you have any interesting server-side error messages?
> 

Comment 12

[Steven Michaud [:smichaud] (Retired)]

One more thing (which I forgot about earlier) -- it's possible that
the Main applet gets its username and password from JavaScript
controls on the Watchguard login page (i.e. that when you're entering
your username and password, that you're not in the Main applet at
all).  In this case the browser's JavaScript console might contain
interesting errors.  To view the JavaScript console choose "JavaScript
Console" from the Tools menu.

Comment 13

[Steven Michaud [:smichaud] (Retired)]

> Also, do you have any interesting server-side error messages?

Please do look for these, or ask someone at your company to do so.

Comment 14

[Derek Merrifield]

There are no entries in the JavaScript console.

(In reply to comment #12)
> One more thing (which I forgot about earlier) -- it's possible that
> the Main applet gets its username and password from JavaScript
> controls on the Watchguard login page (i.e. that when you're entering
> your username and password, that you're not in the Main applet at
> all).  In this case the browser's JavaScript console might contain
> interesting errors.  To view the JavaScript console choose "JavaScript
> Console" from the Tools menu.
> 

Comment 15

[Derek Merrifield]

I am assuming you are wanting to know if any errors are logged on the Firewall?  There is no submission with this issue.  The Java applet never detects that a username has been entered, thus it does not present any creditials for authentication to the Firewall.

(In reply to comment #13)
> > Also, do you have any interesting server-side error messages?
> 
> Please do look for these, or ask someone at your company to do so.
> 

Comment 16

[Steven Michaud [:smichaud] (Retired)]

Well, at this point I'm stuck :-(

I have no way of fixing this problem, or even of knowing what kind of
problem it is, until someone can provide me with a publicly accessible
URL or a test-case applet.

Comment 17

[Derek Merrifield]

This is not an ideal test-case, but there is an applet example that you can see the behavior I am seeing at http://www.javafile.com/password/login/login.php.  This example is actually attempting to do a submission where the applet I am using does not.  The username is "test" and password for this example is "pass".

(In reply to comment #16)
> Well, at this point I'm stuck :-(
> 
> I have no way of fixing this problem, or even of knowing what kind of
> problem it is, until someone can provide me with a publicly accessible
> URL or a test-case applet.
> 

Comment 18

[Steven Michaud [:smichaud] (Retired)]

> We will hold off on upgrading to 1.5.0.7 until this issue can be
> resolve.

Firefox 1.5.0.7 contains a number of security fixes.  So it might be
better for you to downgrade the JEP in Firefox 1.5.0.7 from the
current version (0.9.5+g) to the previous version (0.9.5+f+).

This will be a bit of a pain, since JEP 0.9.5+f+ can't be downloaded
from the Java Embedding Plugin's SourceForge site
(http://javaplugin.sourceforge.net/) -- 0.9.5+f+ was a "special"
version to fix just one problem.  But you can copy the two parts of
JEP 0.9.5+f+ (JavaEmbeddingPlugin.bundle and MRJPlugin.plugin) from
the Contents/MacOS/plugins directory of the Firefox 1.5.0.6 distro and
use them to replace those same two parts in the Firefox 1.5.0.7 distro
(in the same directory).  Both parts need to be replaced (i.e. the
version numbers of JavaEmbeddingPlugin.bundle and MRJPlugin.plugin
need to match).

I'd suggest doing this just once, and putting the result on an
internal server for your company's employees to download.

> Thanks for you prompt attention.

You're quite welcome.

Comment 19

[Steven Michaud [:smichaud] (Retired)]

> http://www.javafile.com/password/login/login.php

Thanks!  I'm able to reproduce your report with this URL.

This is utterly mystifying ... but at least I now have a chance to
figure it out (by trial and error if nothing else).

The problem effects Firefox and Seamonkey, but not Camino.  So it's
presumably a Cocoa-Carbon interface issue.  But I've _never_ seen one
that effects the Java UI (as opposed to the browser's UI).

I tested on OS X 10.4.7 (PPC) and 10.3.9.

Comment 20

[Steven Michaud [:smichaud] (Retired)]

Forgot to mention that I've confirmed that the problem doesn't happen
with JEP 0.9.5+f+ running in Firefox 1.5.0.7 or Seamonkey 1.0.5.

Comment 21

[Daniel Veditz [:dveditz]]

Restoring lost blocking flag

This presumably affects Firefox 2 as well?

Comment 22

[Steven Michaud [:smichaud] (Retired)]

> This presumably affects Firefox 2 as well?

Yes.  I just tested with Firefox 2.0 Beta2.

Please note that it's not true (and the original report doesn't claim)
that _no_ Java text fields will accept text.  As far as I can tell,
only Java text fields that obfuscate their contents (e.g. those used
for passwords) refuse to accept text.

I've changed the description accordingly.

Comment 23

[Steven Michaud [:smichaud] (Retired)]

I've found a fix for this problem.  Since it's a two-line change, I
could make a special release that just adds this change to JEP 0.9.5+g
(as I did with JEP 0.9.5+f+).

I'm working on a couple of major changes for JEP 0.9.5+h, so I don't
think there's any way I can release it before Firefox 2.0 (i.e. 1.8.1)
comes out.

Please let me know _soon_ if you'd like a special release.  Even if
Firefox 2.0 isn't coming out tomorrow, the sooner you have JEP
0.9.5+g+2 in your hands, the more you can test it.  (And, frankly,
Mozilla.org should really be doing a _lot_ more Java testing, and not
just on Mac OS X.)

> So it's presumably a Cocoa-Carbon interface issue.  But I've _never_
> seen one that effects the Java UI (as opposed to the browser's UI).

I was wrong about this.  I'd forgotten that (in JEP 0.9.5+g) I'd made
a very minor alteration to a fix for just such a class of problems, to
tighten up the fix.  But (what I didn't then realize) my fix worked a
bit differently than I thought it did, and my "tightening up" caused
the fix to swallow keystrokes while the focus was in a Java text field
that obfuscated user input.

I did (of course) test JEP 0.9.5+g in Java applets with text input
fields -- which worked just fine.  But I didn't test in my one known
example (a bank site) that used a Java "password field" -- another
site that listed it, along with other banking sites that use Java
applets, had disappeared from the web.  I've now reconstructed that
list by other means ... so I won't lose it again.

Comment 24

[Steven Michaud [:smichaud] (Retired)]

If I do a JEP 0.9.5+g+2, it could (and probably should) also include a
fix for bug 347041.

Mark, what do you think?

Comment 25

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #23)
> Please let me know _soon_ if you'd like a special release.  Even if
> Firefox 2.0 isn't coming out tomorrow, the sooner you have JEP
> 0.9.5+g+2 in your hands, the more you can test it.  (And, frankly,

[...]

> bit differently than I thought it did, and my "tightening up" caused
> the fix to swallow keystrokes while the focus was in a Java text field
> that obfuscated user input.

If the change is safe and small, I'm tempted to say that yes, we'd definitely want it over knowingly regressing password / text obfuscation fields in Java applets. Do you have a sense of how long it would take you to spin up a patch for that? We're doing triage at 11am PDT today, and will make a call on whether or not we'll block for this at that time, so while the patch needn't be ready, some indication of risk and time would be greatly appreciated.

> Mozilla.org should really be doing a _lot_ more Java testing, and not
> just on Mac OS X.)

I'm cc'ing timr on this bug; I bet he'd be happy to get a list of good Java applet testcases from you to be added to Litmus. That's really his call in terms of expending mozilla.com QA resources, but Litmus seems to be a good way to mobilize the mozilla.org community on things like test days, etc.

Comment 26

[Steven Michaud [:smichaud] (Retired)]

> If the change is safe and small

It's certainly small (even if you also include the fix for bug
347041).  And I think it's safe (separately or including the fix for
bug 347041).  But I'm just one guy, and don't (by myself) have the
resources to do really thorough testing.

> Do you have a sense of how long it would take you to spin up a patch

I could have it ready by later today ... though not of course by 11am.
I won't do this as a formal JEP release, so a Mozilla.org server will
need to be available to which it can be posted (whose URL we can
annouce here, and from which testers can download it).  I can email a
copy to whoever's going to post it.  (It'll be too big to just attach
it to this bug.)

> I'm cc'ing timr on this bug; I bet he'd be happy to get a list of
> good Java applet testcases from you to be added to Litmus.

I'd be happy to provide a list.  The list I have now (and use myself)
is pretty informal -- it's just a bunch of interesting or troublesome
sites that I've accumulated.  A few disappear from time to time (or
stop using Java), and others get added as I notice them.  Some aren't
available online in a directly usable format (e.g. zipped up
jar-files-plus-source-code).

What'd _really_ be nice is to have someone scour the net for good
examples or test suites, or (even better) to write up a test suite.
Mozilla.org already has a good (but old) test-suite for non-applet
Liveconnect at
http://www.mozilla.org/quality/browser/front-end/testcases/oji/liveconnecttest.html.
But (of course) that covers only a small corner of the Java universe.
And Sun has it's own test suite (available online at
http://java.sun.com/applets/jdk/1.4/index.html).  But it's not at all
comprehensive.

I suspect that there aren't any really good test suites available.  So
someone would have to write one.  I can't afford the time, and I'm not
sure Mozilla.org would be willing/able to do this either.  But since
you asked ... :-)

Comment 27

[Steven Michaud [:smichaud] (Retired)]

> It's certainly small (even if you also include the fix for bug
> 347041).

Actually, the fix for 347041 _isn't_ so small (I discovered, Mark,
that I can't just drop the check you targeted).  It's probably 50-60
lines altogether, in several different places.  But I think it's safe.

Comment 28

[Steven Michaud [:smichaud] (Retired)]

Attachment: Patch to JEP 0.9.5+g to fix this bug

Here's what it would take to fix this bug.

Comment 29

[Mike Beltzner [:beltzner, not reading bugmail]]

Can we get that landed on trunk ASAP? We haven't made a call about an RC2 for Firefox 2 yet, but in case we do, having it there for a day or two will be helpful.

Thanks for the quick turnaround!

Comment 30

[Mark Mentovai]

(In reply to comment #24)
> If I do a JEP 0.9.5+g+2, it could (and probably should) also include a
> fix for bug 347041.

I'd tend to agree.  Losing dead-keys is a show-stopper for some users.

Comment 31

[Steven Michaud [:smichaud] (Retired)]

I've created and done basic testing on a JEP 0.9.5+g+2 distro that
includes fixes for this bug (bug 353160) and bug 347041.

As I've said above, it needs to find its way to a Mozilla.org server
whose URL can be given here, and from which testers can download it.
Please let me know to whom I should email it, and I'll do that (it's
about 3.5 megs).

I can email it to 2-3 people at most -- after that I might get in
trouble with my ISP.

(After it's on the server, you guys can land it on the trunk, too.)

Comment 32

[Daniel Veditz [:dveditz]]

This shouldn't be assigned to nobody.

Josh, Mark: can one of you step up to get the new JEP into the trunk and branch?

Comment 33

[Josh Aas]

new JEP is posted here:

http://josh.trancesoftware.com/mozilla/JavaEmbeddingPlugin0.9.5+g+2.zip

Comment 34

[Steven Michaud [:smichaud] (Retired)]

Thanks, Josh!

If you want to test JEP 0.9.5+g+2 and your version of
Firefox/Seamonkey already contains a bundled (older) version of the
Java Embedding Plugin, probably your best bet is to do the following:

1) Remove the existing JavaEmbeddingPlugin.bundle and MRJPlugin.plugin
   from your browser's Contents/MacOS/plugins/ directory.
2) Replace them with the JavaEmbeddingPlugin.bundle and
   MRJPlugin.plugin from the JEP 0.9.5+g+2 distro.

It's important to replace _both_ of them.  (The Readme has more
detailed instructions.)

The two fixes that JEP 0.9.5+g+2 contains (for bug 353160 and bug
347041) only have any effect on Carbon-based browsers (since those
bugs only effect Carbon-based browsers).  You can use JEP 0.9.5+g+2
with Camino, and it'll work ... but it won't make any difference.

Comment 35

[Mike Beltzner [:beltzner, not reading bugmail]]

Gah, sorry. My bad. I totally left the FTP window open and forgot to click "send".

Save Josh's bandwidth and get the new JEP here (or in the URL field):

http://people.mozilla.com/~beltzner/JavaEmbeddingPlugin0.9.5+g+2.zip

Comment 36

[Steven Michaud [:smichaud] (Retired)]

I _didn't_ mean to remove the "blocking 1.8.0.8+" flag.  Sorry.

Comment 37

[Josh Aas]

Attachment: JEP 0.9.5+g+2 placeholder

Comment 38

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 239571 [details]
JEP 0.9.5+g+2 placeholder

rs=pink

Comment 39

[Mike Schroepfer]

Comment on attachment 239571 [details]
JEP 0.9.5+g+2 placeholder

Approve for RC2.

Comment 40

[Josh Aas]

Steven - I was about to land this on the 1.8.1 branch when I noticed that there is at least one new file in the JavaEmbeddingPlugin bundle (it is in "Contents", called "PkgInfo"). This is unusual for a JEP update, I want to confirm that you want that new file there before landing. Thanks.

Comment 41

[Steven Michaud [:smichaud] (Retired)]

That's not a new file.  There's been a PkgInfo in the Contents
directory of the JEP distro since the very first version -- at least
of the distros that I've released.

At least on earlier OS X versions (i.e. 10.2.8) it's needed to make
sure the OS's UI treats the bundle as a single "file", instead of as a
directory tree.

Comment 42

[Steven Michaud [:smichaud] (Retired)]

Just to be sure, I've downloaded the JEP 0.9.5+g+2 zipfile from your
URL and Mike Beltzner's URL, and compared them against my own (using
cmp and openssl dgst).  All three are identical.

Comment 43

[Steven Michaud [:smichaud] (Retired)]

I just looked at the JavaEmbeddingPlugin.bundle and MRJPlugin.plugin
bundled with Firefox 2.0 RC1 (i.e. JEP 0.9.5+g) -- both have a PkgInfo
file in their Contents directories (as they should).

Maybe things will look a bit different after a good night's sleep :-)

Comment 44

[Steven Michaud [:smichaud] (Retired)]

For those who are curious, here's the MD5 checksum (openssl dgst or
openssl dgst -md5) of JavaEmbeddingPlugin0.9.5+g+2.zip:

95b1dca7e0092ddbc4d323a05780f256

Comment 45

[Josh Aas]

You're right - PkgInfo is there, its pbdevelopment.plist that is new in JEP 0.9.5+g+2

Comment 46

[Steven Michaud [:smichaud] (Retired)]

Nope, pbdevelopment.plist has also been in the distro since the very
beginning.

Please give me a list of the files/directories you see.

Here's what I see:

ls -alR
.:
total 0
drwxr-xr-x  3 smichaud users  72 2006-07-26 18:04 .
drwxr-xr-x  5 smichaud users 152 2006-07-27 11:42 ..
drwxr-xr-x  4 smichaud users 200 2006-07-26 18:04 Contents

./Contents:
total 12
drwxr-xr-x  4 smichaud users  200 2006-07-26 18:04 .
drwxr-xr-x  3 smichaud users   72 2006-07-26 18:04 ..
-rw-r--r--  1 smichaud users 1000 2006-07-26 18:04 Info.plist
drwxr-xr-x  2 smichaud users  136 2006-07-26 18:07 MacOS
-rw-r--r--  1 smichaud users  358 2006-07-26 18:04 pbdevelopment.plist
-rwxr-xr-x  1 smichaud users    8 2006-07-26 17:52 PkgInfo
drwxr-xr-x  4 smichaud users  104 2006-07-26 17:52 Resources

./Contents/MacOS:
total 1514
drwxr-xr-x  2 smichaud users     136 2006-07-26 18:07 .
drwxr-xr-x  4 smichaud users     200 2006-07-26 18:04 ..
-rwxr-xr-x  1 smichaud users 1544068 2006-07-26 18:07 JavaEmbeddingPlugin
-rwxr-xr-x  1 smichaud users     135 2006-07-26 17:52 JavaEmbeddingPlugin.policy

./Contents/Resources:
total 0
drwxr-xr-x  4 smichaud users 104 2006-07-26 17:52 .
drwxr-xr-x  4 smichaud users 200 2006-07-26 18:04 ..
drwxr-xr-x  2 smichaud users  88 2006-07-26 17:52 English.lproj
drwxr-xr-x  2 smichaud users  88 2006-07-26 17:52 Java

./Contents/Resources/English.lproj:
total 4
drwxr-xr-x  2 smichaud users  88 2006-07-26 17:52 .
drwxr-xr-x  4 smichaud users 104 2006-07-26 17:52 ..
-rwxr-xr-x  1 smichaud users 644 2006-07-26 17:52 InfoPlist.strings

./Contents/Resources/Java:
total 156
drwxr-xr-x  2 smichaud users     88 2006-07-26 17:52 .
drwxr-xr-x  4 smichaud users    104 2006-07-26 17:52 ..
-rw-r--r--  1 smichaud users 157827 2006-07-26 18:04 JavaEmbeddingPlugin.jar

Comment 47

[Steven Michaud [:smichaud] (Retired)]

But now I notice that pbdevelopment.plist isn't in the JEP 0.9.5+g
JavaEmbeddingPlugin.bundle that's bundled with Firefox 2.0 RC1.  Leave
it out, if you want.  It's not needed.

Comment 48

[Steven Michaud [:smichaud] (Retired)]

Side note:  The dates in my list are all wrong -- because I
inadvertently did a list of the files in my JEP 0.9.5+g distro.

Comment 49

[Steven Michaud [:smichaud] (Retired)]

For the sake of tedious completeness, here's the list of
files/directories in JavaEmbeddingPlugin.bundle from my JEP 0.9.5+g+2
distro.  (But, like I said, you can leave out pbdevelopment.plist.)

ls -alR
.:
total 0
drwxr-xr-x  3 smichaud users  72 2006-09-20 16:59 .
drwxr-xr-x  4 smichaud users 128 2006-09-20 21:12 ..
drwxr-xr-x  4 smichaud users 200 2006-09-20 16:59 Contents

./Contents:
total 12
drwxr-xr-x  4 smichaud users  200 2006-09-20 16:59 .
drwxr-xr-x  3 smichaud users   72 2006-09-20 16:59 ..
-rw-r--r--  1 smichaud users 1006 2006-09-20 16:59 Info.plist
drwxr-xr-x  2 smichaud users  136 2006-09-20 17:21 MacOS
-rw-r--r--  1 smichaud users  360 2006-09-20 16:59 pbdevelopment.plist
-rwxr-xr-x  1 smichaud users    8 2006-09-20 16:47 PkgInfo
drwxr-xr-x  4 smichaud users  104 2006-09-20 16:47 Resources

./Contents/MacOS:
total 1518
drwxr-xr-x  2 smichaud users     136 2006-09-20 17:21 .
drwxr-xr-x  4 smichaud users     200 2006-09-20 16:59 ..
-rwxr-xr-x  1 smichaud users 1544532 2006-09-20 17:21 JavaEmbeddingPlugin
-rwxr-xr-x  1 smichaud users     135 2006-09-20 16:47 JavaEmbeddingPlugin.policy

./Contents/Resources:
total 0
drwxr-xr-x  4 smichaud users 104 2006-09-20 16:47 .
drwxr-xr-x  4 smichaud users 200 2006-09-20 16:59 ..
drwxr-xr-x  2 smichaud users  88 2006-09-20 16:47 English.lproj
drwxr-xr-x  2 smichaud users  88 2006-09-20 16:47 Java

./Contents/Resources/English.lproj:
total 4
drwxr-xr-x  2 smichaud users  88 2006-09-20 16:47 .
drwxr-xr-x  4 smichaud users 104 2006-09-20 16:47 ..
-rwxr-xr-x  1 smichaud users 652 2006-09-20 16:47 InfoPlist.strings

./Contents/Resources/Java:
total 156
drwxr-xr-x  2 smichaud users     88 2006-09-20 16:47 .
drwxr-xr-x  4 smichaud users    104 2006-09-20 16:47 ..
-rw-r--r--  1 smichaud users 157827 2006-09-20 16:59 JavaEmbeddingPlugin.jar

Comment 50

[Josh Aas]

checked in on 1.8.1 branch and trunk

Comment 51

[Daniel Veditz [:dveditz]]

Comment on attachment 239571 [details]
JEP 0.9.5+g+2 placeholder

approved for 1.8.0 branch, a=dveditz for drivers

Comment 52

[Josh Aas]

landed on 1.8.0 branch

Comment 53

[Tracy Walker [:tracy]]

verified with:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1) Gecko/20060928 BonEcho/2.0 
and
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.8pre) Gecko/20061002 Firefox/1.5.0.8pre

Comment 54

[WD]

*** Bug 355860 has been marked as a duplicate of this bug. ***