New issue
Advanced search Search tips
Starred by 13 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Nov 2015
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment
link

Issue 71525: deploying java applets with object tag issues a superfluous request for the value specified in the code param.

Reported by jakob.a....@gmail.com, Feb 1 2011

Issue description

Chrome Version       : 10.0.628.0 (Official Build 70488) dev
URLs (if applicable) : http://jakobdams.appspot.com/live-connect-test/index.html
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 5:
  Firefox 3.x: OK
IE 7/8:

What steps will reproduce the problem?
1. Deploy applet with object tag using archive or codebase.
2. Put applet class file in another place than the current location, e.g., in a jar.

What is the expected result?
Nothing

What happens instead?
A request for the file specified via the code param is issued to the basedir.

Please provide any additional information below. Attach a screenshot if
possible.

Deploying with:
<pre style="display: block; ">&lt;object id="1" type="application/x-java-applet" width="100" height="50" &gt;
  &lt;param name="code" value="AppletTest" &lt;&gt;
  &lt;param name="archive" value="applet.jar" &lt;&gt;
&lt;/object&gt;</pre>

Issues a request for {basedir}/AppletTest
 

Comment 1 by jakob.a....@gmail.com, Feb 1 2011

Trying again for better formatting

Deploying with:
<object id="1" type="application/x-java-applet" width="1" height="1" >
  <param name="code" value="AppletTest" />
  <param name="archive" value="applet.jar" />
  <param name="id" value="1" />
</object>

Issues a request for {basedir}/AppletTest

Comment 2 by stuartmorgan@chromium.org, Feb 2 2011

Labels: -Area-Undefined Area-Internals Feature-Plugins

Comment 3 by Deleted ...@, Feb 25 2011

This appears to be the same behavior when using the embed tag as well. Is there a work around for this at the moment?

Comment 4 by ireu...@gmail.com, Aug 4 2011

I'm seeing this as well.  OSX Chrome v13.0.782.107 Java 1.6.26.   I end up with a bunch of errors in my server application log because the browser is requesting a bogus path based on the "code" param.

Comment 5 by staff....@gmail.com, Nov 28 2011

Related bug report: http://code.google.com/p/chromium/issues/detail?id=13750

Chrome 15.0.874.121 m : FAIL

Java version "1.6.0_29"
Java(TM) SE Runtime Environment (build 1.6.0_29-b11)
Java HotSpot(TM) Client VM (build 20.4-b02, mixed mode, sharing)

Comment 6 by Deleted ...@, Jan 17 2012

I am having the same issue with the latest version of Chrome on Ubuntu 11.10
I have XXX.class as my code value
and xyz.jar as my archive value, and it sends a GET request for /URL/XXX.class

Comment 7 by stuartmorgan@chromium.org, Feb 28 2012

 Issue 115880  has been merged into this issue.

Comment 8 by stuartmorgan@chromium.org, Feb 28 2012

Labels: -Area-Internals Area-WebKit
According to the duplicate, this happens in Safari as well, so this should really be filed upstream as WebKit bug.

Comment 9 by thomas.g...@gmail.com, Feb 28 2012

Hi,
is there a separate reference to the webkit issue?
Otherwise would it be possible for you to provide a target date for the fix of this issue?

Thanks in advance,
Thomas

Comment 10 by stuartmorgan@chromium.org, Feb 28 2012

That's "should really be filed" as in "someone needs to file it upstream if it's not already filed". If this is important to you, I encourage you to look in the WebKit bug system for it, and file it if it's not there.

Comment 11 by super...@gmail.com, Jun 15 2012

I am having the same issue with latest Chrome (19.0.1084.56 m) on Windows XP SP3.
Chrome will try to request https://<URL>/com/some/thing/here/TestMain if the object tag contain code tag with value of "com.some.thing.here.TestMain".
In my case, the request will return an error page in "http" protocol but the applet is loaded in https, it will report an SSL security problem prompt.

Comment 12 by bugdroid1@chromium.org, Aug 10 2012

Project Member
Status: IceBox
Summary: deploying java applets with object tag issues a superfluous request for the value specified in the code param.
Closing old bug as obsolete. Please file a new bug (with details) if this problem is still occurring for you.

Comment 13 by stuartmorgan@chromium.org, Aug 30 2012

Status: Untriaged

Comment 14 by stuartmorgan@chromium.org, Aug 30 2012

 Issue 145464  has been merged into this issue.

Comment 15 by k...@ailis.de, Dec 21 2012

I don't really understand the current status of this bug report. You say a new bug should be filed when problem still occurs because this report is obsolete and when someone opens a new bug report then you are closing the bug as a duplicate of this "obsolete" bug...

Well, the problem still occurs in Chrome 23.0.1271.97 on Windows and Linux. But I agree that this is most likely a Webkit bug because it also happens in Safari. I filed a bug report in the Webkit bug tracker:

https://bugs.webkit.org/show_bug.cgi?id=105629

Comment 16 by stuartmorgan@chromium.org, Dec 21 2012

> I don't really understand the current status of this bug report.

It's open; see Status.

> then you are closing the bug as a duplicate of this "obsolete" bug...

And re-opening this one at the same time; see comment 13, where the status changed from closed to Untriaged, on the same day that I dup'd the new bug.

The closing was done by an automated system (note the user for comment 12 is "bugdroid") based on it being old and, at the time, "Unconfirmed". The fact that a human being might override the decision of an automated cleanup bot that operates on simple rules shouldn't be terribly surprising.

Comment 17 by bugdroid1@chromium.org, Mar 10 2013

Project Member
Labels: -Area-WebKit -Feature-Plugins Cr-Content Cr-Content-Plugins

Comment 18 by dploeger...@gmail.com, Mar 14 2013

I have the same on Chrome 25.0.1364.172/OSX 10.7.5

Comment 19 by dszabo...@gmail.com, Mar 20 2013

Workaround: Use APPLET tag instead of OBJECT

Yes, really.

Comment 20 by thomas.g...@gmail.com, Mar 20 2013

Thanks for the workaround suggestion. However, I already tried to use APPLET instead of OBJECT (that's the first thing I tried actually), but in some situation is simply not possible to do so..

Comment 21 by bugdroid1@chromium.org, Apr 6 2013

Project Member
Labels: -Cr-Content Cr-Blink

Comment 22 by bugdroid1@chromium.org, Apr 6 2013

Project Member
Labels: -Cr-Content-Plugins Cr-Internals-Plugins

Comment 23 by cbiesin...@chromium.org, Nov 4 2015

Labels: -Cr-Blink
Status: WontFix
Java is not supported anymore

Sign in to add a comment