noscript not used for non-javascript types




HTML: Parser
16 years ago
4 years ago


(Reporter: Jonathan Howard, Unassigned)



Dependency tree / graph
Bug Flags:
blocking1.4.2 -
blocking1.6 -
blocking1.7a -
blocking1.9.2 -
wanted1.9.2 -

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [HTML4-18.3.1])


(1 attachment)



16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.8) Gecko/20020204
BuildID:    2002020406

When javascript is turned on noscript tags after a script of a different type is
not shown.
see example.

Reproducible: Always
Steps to Reproduce:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
<html xmlns="" xml:lang="en" lang="en">
 <meta http-equiv="Content-type" content="text/html; charset=UTF-8" />

<script type="text/vbscript">
  document.writeln("hello vbscript user")
  text/vbscript not supported; trying text/javascript
  <br />
  <script type="text/javascript">
    document.writeln("hello javascript user")
   text/javascript not supported


Actual Results:  nothing shown

Expected Results:  displayed;
text/vbscript not supported; trying text/javascript
hello javascript user

Comment 1

16 years ago
Assignee: attinasi → harishd
Component: Layout → Parser
Ever confirmed: true
Keywords: mozilla1.0
OS: Windows ME → All
QA Contact: petersen → moied
Hardware: PC → All

Comment 2

16 years ago
You have a SCRIPT within a NOSCRIPT!. What are you trying to do here? Is there a
real web site to this problem? And why should this be considered for mozilla 1.0?

Comment 3

16 years ago
There are several apparent issues here.

HTML 4.01 S18.3.1 says "The NOSCRIPT element allows authors to provide alternate
content when a script is not executed. The content of a NOSCRIPT element should
only be rendered by a script-aware user agent in the following cases:
* The user agent is configured not to evaluate scripts.
* The user agent doesn't support a scripting language invoked by a SCRIPT
element earlier in the document."

The second case is an issue here.  Just because Mozilla supports SCRIPT doesn't
automatically mean that NOSCRIPT should not be displayed.  Specification says
that it should be displayed if "the user agent doesn't support a scripting
language invoked by a SCRIPT element earlier in the document."  So it should be
displayed since Mozilla doesn't support text/vbscript.

There is a problem, though.  The specification is quite general and doesn't
exactly account for the fact that different scripts might be used in different
places.  Logically, a NOSCRIPT should be displayed only after the last
unsupported SCRIPT, but not after another successful SCRIPT.

And finally, the third issue is that people might want to have alternate scripts
embedded in the case that other script types are not supported.  Suppose one
script gets the job done better than the other (in certain browsers), but we
want as much compatibility as possible.  This would logically mean allowing and
parsing SCRIPTs inside NOSCRIPTs.  (It would also mean NOSCRIPTs inside SCRIPTs
inside NOSCRIPTs.. etc.)

Perhaps we need three bugs for this one.  XHTML didn't change this aspect of
HTML4.01 It should be noted that the testcase is valid XHTML (and would be valid
HTML).  While such cases may not be widely deployed, it is because previous
browser support of such things does not exist (to my knowledge) but such things
would be very useful to be able to do.
Keywords: html4

Comment 4

16 years ago
"(It would also mean NOSCRIPTs inside SCRIPTs inside NOSCRIPTs.. etc.)"
should read:
(It would also mean NOSCRIPTs inside NOSCRIPTs inside NOSCRIPTs.. etc.)

Comment 5

16 years ago
>The second case is an issue here.  Just because Mozilla supports SCRIPT doesn't
>automatically mean that NOSCRIPT should not be displayed.  Specification says
>that it should be displayed if "the user agent doesn't support a scripting
>language invoked by a SCRIPT element earlier in the document."  So it should be
>displayed since Mozilla doesn't support text/vbscript.

This sounds like a valid argument. Let me think about this a bit more.

Comment 6

16 years ago
May be we should be supporting this but it ain't going to happen in the 1.0 time
Target Milestone: --- → Future

Comment 7

16 years ago
Pah. The only thing NOSCRIPT is good for is getting rid of ads on certain webhosts.

Seriously, it would take some complex computing to use NOSCRIPT the way you've
suggested. That's not to say this behavior isn't an important thing to
implement, but most scripters have decided to use more advanced methods to
differentiate between script languages and save NOSCRIPT for a last resort. I
wouldn't go so far as to call this an RFE, but this behavior is easily worked
around and not supported in IE. Unfortunately, the way NOSCRIPT works mostly
involves guesswork.

My suggestion for a decent solution is to check to see if *no* scripting
languages supported and enabled in Mozilla have been used since the last
NOSCRIPT. For example, a document that contains only VBScript before the first
NOSCRIPT. That NOSCRIPT should be rendered. But if later in the document,
VBScript is used, followed by JavaScript, and another NOSCRIPT, that second
NOSCRIPT should be ignored. It's very likely the JavaScript was an alternative
to the VBScript in that case, and showing the NOSCRIPT contents would probably
merely cause a second instance of whatever was output in the JavaScript. This
process should restart after each NOSCRIPT.
I may be repeating what someone already said, but the (ideal) accessible
document would contain a <noscript> immediately following each <script> element.
So the right thing to do is display the content of <noscript> if and only if the
<script> element which immediately proceeds it cannot be interpreted.

Comment 9

16 years ago
I think my suggestion of taking the opposite approach is safer. Many stats
programs and advertisers will put several scripting languages in a row followed
by a NOSCRIPT, and have it arranged so that only one of them results in the
display of an image. In situations like this it could cause a double banner ad:

JavaScript code here
(if browser is MSIE do not execute)
VBScript code here
Image counter here

Using my system, there *was* a scripting language recognized by Mozilla
(JavaScript) so the NOSCRIPT will not be rendered. Now, in theory, one might do

JavaScript greeting message here

VBScript clock here
Current time is: <!--#exec cmd=""-->

Mozilla would not render the NOSCRIPT even though the VBScript did not work. The
way to work around this, and I think it's a fair one, is to NOSCRIPT the
previous script:

JavaScript greeting message here
What is your name?
Hello [your name here]!

VBScript clock here
Current time is: <!--#exec cmd=""-->

In fact, the user could even opt to leave the NOSCRIPT empty.

Comment 10

16 years ago
To reaffirm something I meant to say earlier on:

I doubt anyone is ever going to support a nested NOSCRIPT situation like in the
example. There should neither be a SCRIPT nor another NOSCRIPT inside there.
That would be a nice solution to cross-browser compatibility, but it's too
difficult to implement, and it's simple enough to write browser-dependency into
your scripts.
Whiteboard: [HTML4-18.3.1]

Comment 11

15 years ago
The noscript section gets parse in Opera if it doesn't understand the scripting
language, try this:

<script language="VBScript" type="text/vbscript"><!--
  document.write("Hello from VBScript")
  <p>Hello from HTML</p>

Although it is buggy, if you remove the language attribute (which you have to
for XHTML) it will parse the script as JavaScript. I've filed a report to them,
but it would be good if Mozilla could fix this bug too.

Comment 12

14 years ago
Even without nesting <script> tags the behaviour is buggy, e.g.

  <script language="VBScript" type="text/vbscript">
  ' <![CDATA[
document.write "Browser: "
document.write clientInformation.appName
document.write "<br />"
document.write "Version: "
document.write clientInformation.appVersion
  ' ]]>
    clientInformation is only available in Internet Explorer
	(although you could of course use the navigator property :-))

should display the <noscript> content (and does on Opera but not on Mozilla 1.5)
Flags: blocking1.7a-
Flags: blocking1.6-
Flags: blocking1.4.2-
*** Bug 241871 has been marked as a duplicate of this bug. ***


14 years ago
Blocks: 255942


14 years ago
Assignee: harishd → parser
Blocks: 7954
Keywords: mozilla1.0
QA Contact: moied

Comment 14

12 years ago
Regarding comment 11. Opera will keep the "default scripting language" that way given that it is now more or less mendated by HTML5.

Regarding what Opera does, here are some testcases (they have been written so that Opera's implementation passes each of them):

Comment 15

12 years ago
Created attachment 211649 [details]


9 years ago
Flags: wanted1.9.2?
Flags: blocking1.9.2?
Not blocking, but would consider a patch...
Flags: wanted1.9.2?
Flags: wanted1.9.2-
Flags: blocking1.9.2?
Flags: blocking1.9.2-
As far as I can tell, HTML5 back browser behavior here. Hence, this bug is INVALID.
Assignee: parser → nobody
QA Contact: parser

Comment 18

8 years ago
Can you please link to the text where HTML5 backs the current behavior? (I'm not complaining, I'm just interested)
HTML5 has a concept "Scripting is enabled". It isn't tied to support for particular scripting languages.

The parser copies the scripting enabled/disabled from the Document upon parser creation.

The parsing of <noscript> then depends on this flag in the parser.

Marking WONTFIX, since one might argue this is valid per HTML4 but we're now tracking HTML5 instead.
Last Resolved: 8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.