60724 - <script> tag inside <applet> tag executes if Java enabled

Status: RESOLVED DUPLICATE of bug 253346

(Core :: DOM: HTML Parser, defect, P3)

Description

[Bill Lipa]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001108 Netscape6/6.0
BuildID:    Gecko/20001117

In Netscape 6/Mozilla with Java installed and enabled, you will receive an
incorrect alert using the following HTML code because Javascript that's inside
an applet tag is executed regardless of whether or not Java is enabled.  In NS4
and IE, Javascript inside an applet tag is only executed if Java is disabled,
which is the correct behavior.

Quoting from the HTML 4.01 spec:
The content of the APPLET acts as alternate information for user agents that
don't support this element or are currently configured not to support applets.
User agents must ignore the content otherwise.

This feature provides a way to detect this condition within Javascript and take
appropriate action, for example redirecting to a page that explains the
situation to a user.

Reproducible: Always
Steps to Reproduce:
Load the attached HTML file in Mozilla or Netscape 6. For the test to be valid,
Java must be installed and enabled.  Compare with NS4 or IE.

Actual Results:  Saw the alert which indicated that Javascript inside an applet
tag was exectuting, despite the fact that Java was running properly.

Expected Results:  Should have supressed execution of the Javascript, since Java
was running.

Comment 1

[Bill Lipa]

Attachment: test case

Comment 2

[Boris Zbarsky [:bzbarsky]]

Confirming bug.  I see this on linux build 2000-12-05-08

Comment 3

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Andrei, know the proper owner for this bug?

Comment 4

[Daniel Kirkdorffer]

Actually, I observe the exact opposite problem: my Javascript inside my APPLET 
tag DOES NOT execute when Java is disabled.  What I've observed is that the 
contents between the APPLET tags are entirely ignored when Java is disabled.  

I have a page at http://www.elephant-talk.com/marquee.htm that displays a 
scrolling banner applet if Java is enabled, but if Java is not enabled it 
displays a Javascript scrolling marquee, and if Javascript is not enabled it 
displays message.  In Netscape 6 when Java is not enabled it shows nothing.

I am using Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20001108 
Netscape6/6.0 which I just downloaded.

Obviously the mechanisms in play here are whacked out if it can't get it right 
either way.  This is a major bug, nothing normal about this.

Comment 5

[av (gone)]

George, should this one be one of yours?

Comment 6

[drapeau]

av: don't know if it should be OJI, but I'll assign it to Ed Burns for
investigation; if he determines it belongs in another component, I'm sure he'll
assign it back.  Doesn't sound as if it's OJI, though, since it's the core
deciding to evaluate the contents of JavaScript inside an APPLET tag.

Comment 7

[Hixie (not reading bugmail)]

Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.

Comment 8

[bsharma]

qa contact updated.

Comment 9

[edburns]

I'm happy to say that after visiting the court of the Crimson King, I have 
found this this bug does not occurr with today's trunk.  Here are the steps I 
took to verify.

0. de-install java plugin
1. un-check Enable Java preference
3. Visit page: saw javascript scrolling message

Close browser

4. install java plugin
5. check Enable java plugin
6. Visit page, saw java applet banner
7. Check disable java
8. Shift-reload
9. See javascript banner.

Comment 10

[bsharma]

Verified on
build: 2001-05-29-20-Trunk
platform: Win NT

I have java installed (verified with about:plugins) but when I load the attached 
html, the JS alert dialog appears.

Comment 11

[Heikki Toivonen (remove -bugzilla when emailing directly)]

SPAM. HTML Element component deprecated, changing component to Layout. See bug
88132 for details.

Comment 12

[Bill Lipa]

Note that this is an HTML spec compliance bug that causes serious problems for
usability of sites that rely on Java applets.

Comment 13

[Peter Lubczynski]

-->over to the parser for now. Not sure if that's the best owner, feel free to
bounce back but I've got no idea what needs to be done to prevent script tags
from running in these situations.

Comment 14

[Martin Sch]

Text inside java applets is not displayed if java is disabled.
A lot of applets have a text like "you don't see anything because java is
disabled in your browser"

Comment 15

[Peter Lubczynski]

Confirming this is still happening on branch builds. We seem to always execute
these <script> tags when inside plugin tags. :(

Would it be possible to abort running these script tags if we know we have a plugin?

Comment 16

[Mats Palmgren (inactive)]

*** Bug 227068 has been marked as a duplicate of this bug. ***

Comment 17

[Boris Zbarsky [:bzbarsky]]

It's not really clear what should be going on here... realistically, the DOM
nodes for content under the <object> or <applet> should probably be created no
matter what.  Whether they get rendered depends on whether the <object> or
<applet> exists.  Anything else is not really implementable (suddenly having to
reparse the page because we discover that the applet is a 404 or some insanity
like that).

Which would mean that the currnet behavior is correct.

Comment 18

[Bill Lipa]

I don't think the spec is at all ambiguous that the current behavior is NOT
correct.  It states:

>The content of the APPLET acts as alternate information for user agents that
>don't support this element or are currently configured not to support applets.
>User agents must ignore the content otherwise.

This has nothing to do with applet data not being found or DOM nodes being
created.  Mozilla is not ignoring the content when it is configured to not
support applets, so it is incorrect.

Comment 19

[Boris Zbarsky [:bzbarsky]]

Bill, Mozilla is a CSS browser, not an HTML one.  So we do in fact have to
construct a DOM to even start rendering a page.

The problem is that the alternate content needs to be rendered even if Java _is_
enabled by the applet is not available (say the server responds with a 404).  So
at that point the childnodes of the <applet> need to be in the DOM, pure and
simple.  There is no way to go back and somehow "get" them.

Comment 20

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Actually i would argue that we're a HTML browser too and comment 18 is correct.
What we IMHO should do (and this applies to more elements then <script>) is to
walk up the parentchain and see if there is a parent that 'disables' us. This
should be fairly easy to do by having some sort of |PRBool
nsGenericElement::DisablesChildren()| function that walks up the chain and asks
each element if it should be disabled. This function should be called by
<meta>, <script>, <style>, <embed> etc.

And <embed>, <noscript>, <noframes>, <applet> etc should override this function
and return true if needed.

This would IMHO be a much more correct way to disable elements then to do what
we do now.

Comment 21

[Boris Zbarsky [:bzbarsky]]

Sicking, comment 18 and what you propose have very little in common.  Your
proposal may actually be workable.  How do you propose handling the situation
when java _is_ enabled but the applet is not available?  At that point we need
to reenable all the kids of the <applet> in the right order.

Comment 22

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

IMHO we should ignore the contents there too. The spec says

"don't support this element or are currently configured not to support applets"

which doesn't include when the applet isn't available. IMHO what we do now is
fine, just render something indicating that something failed.

Unfortunatly it gets worse for <object> which says that the contents should be
rendered if the object can't for "whatever reason".

One thought that occured to me. If we had better BindToDocument code we could
maybe hack that so that children of disabling elements doesn't get their
mDocument set. This was we would automatically disable them, and if we decide we
need to render/activate them we'd just set their mDocument.

This is definitly a bit evil since it might confuse code that is navigating
around in the document, but it seems like it could be a neat solution to this
particular bug.

Comment 23

[Boris Zbarsky [:bzbarsky]]

> Unfortunatly it gets worse for <object> which says that the contents should be
> rendered if the object can't for "whatever reason".

There's really no good reason to treat the two differently -- we should be using
the <object> behavior for both.

Not setting mDocument... hmm... yeah, that may work.  We need to implement
BindToDocument first....

Comment 24

[Hixie (not reading bugmail)]

In the ideal world, imagine this:

   <script> ...1... </>
   <object data="test.cgi">
    <script> ...2... </>
   </object>
   <script> ...3... </>

...where test.cgi takes 2 minutes then returns 404.

What order would the scripts execute in? What if they all contain
document.write() calls? I assume IE fails ass-backwards on this test?


Mozilla is primarily a DOM+CSS browser, not an HTML browser. It just happens to
support the built-in semantics of HTML, XHTML, and MathML elements when their
semantics don't clash with DOM and CSS rules. Speaking of DOM rules, I assume
the proposal above to not set mDocument doesn't break the DOM rule that all
nodes have a document...?

Comment 25

[Bill Lipa]

While that is an interesting question, I don't think it has anything to do with
the original bug.  The original bug is about the spec-defined case which governs
"user agents that don't support this element or are currently configured not to
support applets".  The success, failure, or duration of network retrievals is
irrelevant.

Comment 26

[Boris Zbarsky [:bzbarsky]]

Bill, there is absolutely no difference, really, between an object not rendering
because we can't get the data and an object not rendering because Java is off. 
Now the HTML spec specifies a different behavior for <applet> and <object>, but
we don't really implement the deprecated <applet> tag... we treat it more or
less as a synonym for <object>.  We don't really plan to write thousands of
lines of separate code for <applet>, since as I pointed out it's deprecated.  So
the question is what the right solution for <object> is.  The same solution
should apply to applet.

Comment 27

[Bill Lipa]

In all browsers except for Mozilla, it is possible to detect the Java-disabled
case by putting a script to handle this case inside the contents of the applet
tag.  This is the behavior mandated by the HTML spec.  And, I believe this is
the only spec-compilant, (formerly) portable way to detect Java being disabled,
so the lack of this functionality is a reliability problem for sites that use Java.

I would argue that the HTML spec requires you to ignore the contents in the case
that the applet cannot be retrieved, because user agents "must ignore" the
contents except in two cases, neither of which involves a retrieval problem.  IE
implements the behavior correctly.

The object tag is different; this bug is not about the object tag.  It is about
a spec compilance and portability problem with the applet tag.