Closed Bug 60724 Opened 19 years ago Closed 10 years ago
<script> tag inside <applet> tag executes if Java enabled
Confirming bug. I see this on linux build 2000-12-05-08
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 98 → All
Andrei, know the proper owner for this bug?
Assignee: clayton → av
George, should this one be one of yours?
Assignee: av → drapeau
Assignee: drapeau → edburns
Reassigning QA Contact for all open and unverified bugs previously under Lorca's care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok
qa contact updated.
QA Contact: gerardok → bsharma
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
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.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
SPAM. HTML Element component deprecated, changing component to Layout. See bug 88132 for details.
Component: HTML Element → Layout
Note that this is an HTML spec compliance bug that causes serious problems for usability of sites that rely on Java applets.
-->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.
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"
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?
*** Bug 227068 has been marked as a duplicate of this bug. ***
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.
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.
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.
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.
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.
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.
> 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....
Depends on: 211128
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...?
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.
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.
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.
Assignee: harishd → parser
Status: ASSIGNED → NEW
QA Contact: moied → mrbkap
Assignee: parser → nobody
QA Contact: mrbkap → parser
Status: NEW → RESOLVED
Closed: 19 years ago → 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 253346
You need to log in before you can comment on or make changes to this bug.