Closed Bug 127137 Opened 23 years ago Closed 15 years ago

noscript not used for non-javascript types

Categories

(Core :: DOM: HTML Parser, defect)

Product:
Core
Component:
DOM: HTML Parser
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: jonathan2, Unassigned)

References

Details

(Keywords: html4, Whiteboard: [HTML4-18.3.1])

Attachments

(1 file)

testcase
295 bytes, text/html
Details 
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="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
 <meta http-equiv="Content-type" content="text/html; charset=UTF-8" />
 <title>Test</title>
</head>
<body>

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

</body>
</html>



Actual Results:  nothing shown

Expected Results:  displayed;
text/vbscript not supported; trying text/javascript
hello javascript user
->Parser
Assignee: attinasi → harishd
Status: UNCONFIRMED → NEW
Component: Layout → Parser
Ever confirmed: true
Keywords: mozilla1.0
OS: Windows ME → All
QA Contact: petersen → moied
Hardware: PC → All
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?
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
"(It would also mean NOSCRIPTs inside SCRIPTs inside NOSCRIPTs.. etc.)"
should read:
(It would also mean NOSCRIPTs inside NOSCRIPTs inside NOSCRIPTs.. etc.)
>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.


May be we should be supporting this but it ain't going to happen in the 1.0 time
frame.
Target Milestone: --- → Future
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.
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:

<SCRIPT LANGUAGE="JavaScript">
JavaScript code here
(if browser is MSIE do not execute)
</SCRIPT>
<SCRIPT LANGUAGE="VBScript">
VBScript code here
</SCRIPT>
<NOSCRIPT>
Image counter here
</NOSCRIPT>

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
this:

<SCRIPT LANGUAGE="JavaScript">
JavaScript greeting message here
</SCRIPT>

<SCRIPT LANGUAGE="VBScript">
VBScript clock here
</SCRIPT>
<NOSCRIPT>
Current time is: <!--#exec cmd="clock.pl"-->
</NOSCRIPT>

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:

<SCRIPT LANGUAGE="JavaScript">
JavaScript greeting message here
</SCRIPT>
<NOSCRIPT>
What is your name?
Hello [your name here]!
</NOSCRIPT>

<SCRIPT LANGUAGE="VBScript">
VBScript clock here
</SCRIPT>
<NOSCRIPT>
Current time is: <!--#exec cmd="clock.pl"-->
</NOSCRIPT>

In fact, the user could even opt to leave the NOSCRIPT empty.
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]
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")
'--></script>
<noscript>
  <p>Hello from HTML</p>
</noscript>
  </body>

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.
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
  ' ]]>
  </script>
  <noscript>
    clientInformation is only available in Internet Explorer
	(although you could of course use the navigator property :-))
  </noscript>

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. ***
Assignee: harishd → parser
Blocks: html4.01
Keywords: mozilla1.0
QA Contact: moied
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):
 <http://annevankesteren.nl/test/html/noscript/>
Attached file testcase — 

    
  
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

    
    

    
  
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.
http://www.whatwg.org/specs/web-apps/current-work/#concept-bc-script

The parser copies the scripting enabled/disabled from the Document upon parser creation.
http://www.whatwg.org/specs/web-apps/current-work/#scripting-flag

The parsing of <noscript> then depends on this flag in the parser.
http://www.whatwg.org/specs/web-apps/current-work/#parsing-main-inhead

Marking WONTFIX, since one might argue this is valid per HTML4 but we're now tracking HTML5 instead.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: