<APPLET> triggers plugin downloader plugin




18 years ago
16 years ago


(Reporter: neil, Assigned: serhunt)


Windows 95

Firefox Tracking Flags

(Not tracked)





18 years ago
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

18 years ago
I can reproduce this but dunno how critical this is.

Comment 2

18 years ago
Some sites use something along these lines to detect Java support:
<form ...>
<input type=hidden name=java value=false>
If java is enabled, the hidden field should not submit.
If java is disabled or unsupported, the hidden field submits.
What happens if you load a page such as the markup you just specified?

Comment 4

18 years ago
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.
Keywords: 4xp
Target Milestone: --- → Future
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

18 years ago
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

18 years ago
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)
	      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: dbaron@fas.harvard.edu
(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

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

Comment 9

16 years ago
this is a wfm, need QA verification
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME

Comment 10

16 years ago
I can't verify this because an empty <APPLET> tag currently hangs Mozilla.
You need to log in before you can comment on or make changes to this bug.