Closed Bug 638171 Opened 10 years ago Closed 10 years ago

FireFox does not read Java Plugin Info.plist correctly.


(Core :: Plug-ins, defect)

Not set



Tracking Status
blocking2.0 --- Macaw+
status2.0 --- .1-fixed


(Reporter: bino_george, Assigned: benjamin)



(Keywords: regression, relnote, Whiteboard: [fx4-unco-bugday][fx4-rc-ridealong][scares-beltzner])


(1 file, 2 obsolete files)

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_6; en-US) AppleWebKit/534.13 (KHTML, like Gecko) Chrome/9.0.597.107 Safari/534.13
Build Identifier: 4.0b11

The Java Plugin2 has an Info.plist that specifies all the mimetypes supported by the plugin. However, only part of this list is read and some parts are ommitted. I found that the the presence of any versions that have three or more digits causes the rest of the plist to not be read correctly :

If you remove all of the x.x.x entries such as :

      <string>Java applet</string>
      <string>Java applet</string>
      <string>Java applet</string>

It works fine and then reads the rest of the list.

Basically, about:plugins should reflect all the versions specified in the Info.plist.

Reproducible: Always

Steps to Reproduce:
type about:plugins in the URL field.

You will see that the list is not the complete list that is specified in the Info.plist :


Expected Results:  
about:plugins should have the full list of versions from the WebPluginMIMETypes dict of the plist here :

Does this occur in the latest Fx 4 beta?

Is this broken in 3.6.x as well, or is it an Fx4 regression?
Component: General → Plug-ins
Product: Firefox → Core
QA Contact: general → plugins
Version: unspecified → Trunk
It is a Fx4 regression, it works fine in FireFox 3 according to my testing.
Would you be able to try and find the regression range:
Severity: critical → major
Also, before doing the above, can you verify it still exists in the latest nightly (to save unnecessary effort on your part!):
Bino, can you please try to reproduce this with Firefox 4.0rc1 or the latest Minefield nightly? If so, please try to find a regression range using the tool in comment 3.  If you need help with any of this please let us know.
Whiteboard: [fx4-unco-bugday]
Ever confirmed: true
Duplicate of this bug: 640483
(gdb) p *info.fMimeTypeArray@17
$13 = {0x1207e72f0 "application/x-java-applet;version=1.1.3", 0x1207e7370 "application/x-java-applet", 0x1207e73c0 "application/x-java-applet;jpi-version=1.6.0_22", 0x1207e7450 "application/x-java-applet;version=1.2.2", 0x1207e7500 "application/x-java-applet;version=1.5", 0x1207e75a0 "application/x-java-applet;version=1.3.1", 0x1207e7650 "application/x-java-applet;version=1.3", 0x1207e76f0 "application/x-java-vm", 0x1207e7760 "application/x-java-applet;version=1.1.2", 0x1207e7810 "application/x-java-applet;version=1.1", 0x1207e78b0 "application/x-java-vm-npruntime", 0x1207e7940 "application/x-java-applet;version=1.2.1", 0x1207e79f0 "application/x-java-applet;version=1.6", 0x1207e7a90 "application/x-java-applet;version=1.4.2", 0x1207e7b40 "application/x-java-applet;version=1.4", 0x1207e7be0 "application/x-java-applet;version=1.1.1", 0x1207e7c90 "application/x-java-applet;version=1.2"}

We cut off the list after we see application/x-java-vm-npruntime intentionally:

But on mac at least, PList dictionaries are not order-sensitive, so it's a bit random where that particular entry would be in the list.

jst added this short-circuit in bug 393928

jst, do you remember why you added that check in the first place, and whether I can just remove it, either for mac or for all platforms?

Nominating for blocking based on the dup bug 640483 which has us breaking java in the wild, and this being a regression from 3.6 because we switched from JEP to JavaPlugin2.
blocking2.0: --- → ?
Assignee: nobody → benjamin
Attachment #518853 - Flags: review?(jst)
Comment on attachment 518853 [details] [diff] [review]
Don't ignore following MIME types, rev. 1

+  if (javaSentinelVariant != -1) {
+    if (mVariants > javaSentinelVariant + 1) {
+      memmove(mMimeTypeArray + javaSentinelVariant + 1,
+              mMimeTypeArray + javaSentinelVariant,
+              (mVariants - javaSentinelVariant - 1) * sizeof(mMimeTypeArray[0]));
+      if (mExtensionsArray) {
+        memmove(mExtensionsArray + javaSentinelVariant,
+                mExtensionsArray + javaSentinelVariant + 1,
+                (mVariants - javaSentinelVariant - 1) * sizeof(mExtensionsArray[0]));
+      }
+    }
+    mMimeTypeArray[mVariants] = NULL;
+    if (mExtensionsArray)
+      mExtensionsArray[mVariants] = NULL;
+    mMimeDescriptionArray.RemoveElementAt(javaSentinelVariant);
+    mVariants--;
+  }

This leaks the strings held in mMimeTypeArray[javaSentinelVariant] and 
mExtensionsArray[javaSentinelVariant]. I wonder if this wouldn't be cleaner to have a javaSentinelOffset that starts out as 0 and gets set to -1 in the case where we see the sentinel mimetype, and then add javaSentinelOffset to i in the loop above (and we'd need to 'continue' when we hit the sentinel mimetype as well). That way we wouldn't need to do any memmove's etc.

r- until the leak is fixed, one way or another.
Attachment #518853 - Flags: review?(jst) → review-
I just did the freeing here, and factored this into a helper function.

On trunk it would be great to make these use nsTArray, but that's a bit too much for the immediate term.
Attachment #518853 - Attachment is obsolete: true
Attachment #519178 - Flags: review?(jst)
Attachment #519178 - Flags: review?(joshmoz)
blocking2.0: ? → .x+
Keywords: relnote
Whiteboard: [fx4-unco-bugday] → [fx4-unco-bugday][fx4-rc-ridealong][scares-beltzner]
Attachment #519178 - Flags: review?(jst) → review+
Looks good to me, this should force a pluginreg refresh but somebody should confirm that it works.
Attachment #519178 - Attachment is obsolete: true
Attachment #519178 - Flags: review?(joshmoz)
Attachment #519738 - Flags: review+
This bug is the same as 9064651 in Apple bugreporter (  : rdar://problem/9064651
relnote: "Firefox on Mac OS X running in 64-bit mode does not recognize that Java supports the MIME type 'application/x-java-applet;version=1.6', which may cause some sites, including to stop working or ask you to upgrade Java, even though it is already up to date. Workaround: run Firefox in 32-bit mode (link to SUMO article)." I can't actually find the SUMO link, although I've been told there is an article explaning it somewhere.
Whiteboard: [fx4-unco-bugday][fx4-rc-ridealong][scares-beltzner] → [fx4-unco-bugday][fx4-rc-ridealong][scares-beltzner][not-ready]
Attachment #519738 - Attachment is patch: true
Attachment #519738 - Attachment mime type: application/octet-stream → text/plain
Whiteboard: [fx4-unco-bugday][fx4-rc-ridealong][scares-beltzner][not-ready] → [fx4-unco-bugday][fx4-rc-ridealong][scares-beltzner]
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.2
Is it safe to fix this regression on the mozilla2.0 branch for Fx4.0.1? provisionally blocking due to "fc4-ridealong" notation.
Blocks: 393928
blocking2.0: .x+ → Macaw
I think it's safe enough.
Attachment #519738 - Flags: approval2.0?
Comment on attachment 519738 [details] [diff] [review]
rev 1.2, w/pluginreg refresh

Approved for the mozilla2.0 repository, a=dveditz for release-drivers
Attachment #519738 - Flags: approval2.0? → approval2.0+
You need to log in before you can comment on or make changes to this bug.