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.
Created attachment 79399 [details] Java applet loaded OK in Flash environment
<rdar://problem/8884224>
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.
(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.
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.
Created attachment 87664 [details] Patch
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.
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
(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
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.
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.
Created attachment 87807 [details] Patch
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.
Committed r82646: <http://trac.webkit.org/changeset/82646>