51040 - <APPLET> triggers plugin downloader plugin

Status: RESOLVED WORKSFORME

(Core Graveyard :: Plug-ins, defect, P3)

Description

[[e-mail]]

1. Create a file containing only the 8 characters <APPLET>
2. Open the file in Mozilla.

Expected results: Blank page.

Actual results: Plugin downloader plugin message.

Additional information: Java is enabled. Correct APPLET tags load normally.

Comment 1

[shrirang khanzode]

I can reproduce this but dunno how critical this is.

Comment 2

[[e-mail]]

Some sites use something along these lines to detect Java support:
<form ...>
<applet>
<input type=hidden name=java value=false>
</applet>
</form>
If java is enabled, the hidden field should not submit.
If java is disabled or unsupported, the hidden field submits.

Comment 3

[ekrock's old account (dead)]

What happens if you load a page such as the markup you just specified?

Comment 4

[[e-mail]]

The reason that I sumbitted this bug is that I got the plugin downloader plugin 
message when I viewed the sign-in screen for our internal mail; in fact this 
also caused the web-based mail configurator to believe that I had disabled java.

Comment 5

[ekrock's old account (dead)]

I'm afraid this gets Futured as Netscape's engineers are overburdened. cc:ing 
George Drapeau for his input on how severe a problem this might be.

Comment 6

[drapeau]

I believe this is one of the unfortunate side effects of the new way of 
integrating a JVM into the browser: now that the Java support is done as a 
plug-in, every time the browser sees the MIME type of "application/x-java-vm", 
it behaves as if it's looking for the appropriate plugin.

Using the APPLET tag to verify whether Java support is there is a neat trick, 
but for now it won't work without the side effects you've seen.  I would 
consider this an RFE for a future release.  In the mean time, if you're looking 
for a way in Netscape 6 and/or Mozilla to determine whether Java is working, I 
can try to help you with that.

Comment 7

[edburns]

This brings up an interesting problem.  The reason the Plugin DownloaderPlugin 
is mentioned is that the URL passed to the plugins module is null.

The reason the URL is null is found in nsObjectFrame::Reflow():

if (atom == nsHTMLAtoms::applet && atom) 
{
  mimeType = (char *)PR_Malloc(PL_strlen("application/x-java-vm") + 1);
  PL_strcpy(mimeType, "application/x-java-vm");
  
  if (NS_CONTENT_ATTR_HAS_VALUE == mContent->GetAttribute(kNameSpaceID_HTML, 
nsHTMLAtoms::code, src)) 
    {
      
      nsAutoString codeBase;
      if (NS_CONTENT_ATTR_HAS_VALUE == mContent->GetAttribute
(kNameSpaceID_HTML, nsHTMLAtoms::codebase, codeBase)) 
	{
          nsIURI* codeBaseURL = nsnull;
          rv = NS_NewURI(&codeBaseURL, codeBase, baseURL);
          if(rv == NS_OK)
	    {
	      NS_IF_RELEASE(baseURL);
	      baseURL = codeBaseURL;
	    }
        }
      
      // Create an absolute URL
      rv = NS_NewURI(&fullURL, src, baseURL);
    }
  
  rv = InstantiatePlugin(aPresContext, aMetrics, aReflowState, pluginHost, 
mimeType, fullURL);
}

We never call NS_NewURI if the applet has no code HTMLAtom, thus fullURL passed 
into InstantiatePlugin() is null. I don't know if this is correct behavior.  
Adding CC: [e-mail]

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(Not sure why you cc'ed me, but anyway...)  The HTML4 spec says either CODE or
OBJECT attribute is required.  (I don't understand what OBJECT is for.)  See
http://www.w3.org/TR/html4/struct/objects.html#h-13.4

If there's no CODE attribute, do you need to call |InstantiatePlugin|?  Could it
just be moved up inside the block?

Comment 9

[rubydoo123]

this is a wfm, need QA verification

Comment 10

[[e-mail]]

I can't verify this because an empty <APPLET> tag currently hangs Mozilla.