Bug 52703 – REGRESSION: Java applet fails to load when <object> has a classid attribute

• Component: Java
• Status: RESOLVED FIXED

[Raphael Maes]

Created attachment 79398 [details]
Java applet load fails in Flash environment

Latest WebKit nightly builds show a regression issue when loading Java applets from within a Flash-player environment. (Its no issue when loaded from within an HTML context)

The applet fails to load, and a partially visible <object> fallback text was displayed (see attachment).

- WebKit nightly build r75772
- Adobe Flash-player v10.1.x
- Java v1.6.0_22

The screenshot '' shows a failed Java applet (red 'X') and a fallback text. See the 'Java_applet_in_Flash_OK' screenshot for a correctly loaded applet.

To reproduce: 
 - URL : http://delano-eqa.tst.agfa.com/PageMaster
 - In the logon dialog box : Click the link "Check my system". This wil show a floating window executing different system checks.

[Raphael Maes]

Created attachment 79399 [details]
Java applet loaded OK in Flash environment

[Alexey Proskuryakov]

<rdar://problem/8884224>

[Andy Estes]

I can reproduce the failure, but it doesn't appear to be a regression from shipping Safari. I see the same failure to load Java in Safari 5.0.4 on Snow Leopard with Java 1.6 installed.

[Andy Estes]

(In reply to comment #3)
> I can reproduce the failure, but it doesn't appear to be a regression from shipping Safari. I see the same failure to load Java in Safari 5.0.4 on Snow Leopard with Java 1.6 installed.

A colleague was able to verify this is a regression on his Snow Leopard machine.

[Andy Estes]

I can reproduce it now. Here is the start of the object tag that embeds Java:

<object classid="java:com.agfa.delano.applet.preload.Preload.class" type="application/x-java-applet" archive="applet-preload.jar,applet-streamproofnt.jar,applet-common.jar,httpclient.jar,commons-logging-signed.jar,commons-httpclient-signed.jar,commons-codec-signed.jar,streamproof_model-signed.jar,xbean-signed.jar,xmlbeans-qname-signed.jar,jsr173_1.0_api-signed.jar,apxproxy_model-signed.jar,ehcache-signed.jar,iText-signed.jar,iText-toolbox-signed.jar,bcmail-signed.jar,bcprov-signed.jar" width="100%" height="100%" id="PreloaderApplet">

Due to the non-empty classid, we immediately render fallback content. However, in this case there is a valid type attribute, and the classid attribute is clearly being co-opted to mean something other than "ActiveX/COM classid". We should probably relax our fallback rule to simply ignore non-empty classids (i.e. do not give them special meaning) rather than immediately rendering fallback content when we encounter one. If we were to do this here, we'd see a valid MIME type in the type attribute and successfully load the Java plug-in, passing the rest of the attributes as params to the plug-in.

[Andy Estes]

Created attachment 87664 [details]
Patch

[Alexey Proskuryakov]

Comment on attachment 87664 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=87664&action=review

Nice fix!

> Source/WebCore/ChangeLog:5
> +        REGRESSION: Java applet fails to load from within Adobe Flash-player environment

Please update the bug title.

> Source/WebCore/ChangeLog:13
> +        In r70748 we removed our mapping of several known ActiveX classids to
> +        MIME types. In the process of doing so, we decided to strictly adhere
> +        to HTML5 by rendering fallback content whenever we encounter an object
> +        with a non-empty, non-recognized classid. This turned out to be too
> +        strict, as some plug-ins (e.g. Java and Qt application plug-ins) co-opt
> +        the classid attribute to store valid, plug-in specific bits.

If this patch makes us diverge from the spec, please don't land it without filing a bug in HTML5 Bugzilla (no need to wait for its resolution IMO).

> LayoutTests/ChangeLog:5
> +        REGRESSION: Java applet fails to load from within Adobe Flash-player environment

Please update the bug title.

[Raphael Maes]

Hi,

Thanks for the work on this issue.
I'm sorry for my lack of knowledge on the Webkit build process, but does this patch activity mean it is available in the latest nightly build ?

Thanks,
Raphael Maes

[Andy Estes]

(In reply to comment #8)
> Hi,
> 
> Thanks for the work on this issue.
> I'm sorry for my lack of knowledge on the Webkit build process, but does this patch activity mean it is available in the latest nightly build ?

It does not. Alexey reviewed the patch which means I can now land it to the tree. When that happens I will add a comment to this bug indicating the SVN revision number containing this change, and that change will be included in the next nightly build.

> 
> Thanks,
> Raphael Maes

[Andy Estes]

Unfortunately this change will cause <https://bugs.webkit.org/show_bug.cgi?id=45679> to be re-opened, so I need to think a little more about this patch. I'm going to remove the review flag for the time being.

[Andy Estes]

It turns out that Gecko explicitly supports classids starting with "java:" (<http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsObjectLoadingContent.cpp#1728>). I think it makes more sense to do that instead of deviating from the spec by ignoring non-empty classids. New patch on the way.

[Andy Estes]

Created attachment 87807 [details]
Patch

[Alexey Proskuryakov]

Comment on attachment 87807 [details]
Patch

Please add Java tests with different order of attributes (type/classid vs. classid/type). We historically had some issues with trying to look at an attribute that hasn't been parsed yet.

[Andy Estes]

Committed r82646: <http://trac.webkit.org/changeset/82646>