Closed Bug 67994 Opened 24 years ago Closed 24 years ago

blank page rendered if form in header

Categories

(Core :: DOM: HTML Parser, defect)

Product:
Core
Component:
DOM: HTML Parser
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 66985

People

(Reporter: faelan, Assigned: harishd)

Details

(Keywords: testcase)

Attachments

(3 files)

screen shot of 'fixed' doctype results.
32.89 KB, image/png
Details
Testcase w/ correct DOCTYPE
830 bytes, text/html
Details
Filer page
85 bytes, text/html
Details 
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT; Standard Register 
IE50)
BuildID:    2001020704

Pages with a form inside a head block don't render.  At all.  The HTML files 
included in the Additional Information section can be used to reproduce this 
problem.



Reproducible: Always
Steps to Reproduce:
test.html and sample-page.html are included in the 'Additional Information'
1. Load test.html in Mozilla
2. marvel at the blank page you are presented with
3. Load test.html in IE 5 or Netscape 4.76 to see how it is rendered there.

Actual Results:  Mozilla renders nothing, except the title of the page in the 
title bar.

Expected Results:  Based on how IE 5 and Netscape 4.76 render the page, Mozilla 
should allow forms within the header.  I don't know how common a problem this 
is, but it's a problem with two projects where I work.

Here's the main page in question (test.html):
- - - - -
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
	<head>
		<title>Look, a &lt;form&gt; in the &lt;head&gt;er!</title>
		<form target="system_help" name="system_help_form" 
method="post" action="ts_help.asp">
			<input type="hidden" name="SystemHelpKey">
			<input type="hidden" name="CustomHelpKey">
		</form>
	</head>

	<frameset rows="105,*,40" frameborder="0" framespacing="0">
		<frame marginheight="0" scrolling="no" src="sample-page.html" 
name="header">
		<frameset cols='205,*' frameborder='0' framespacing='0'>
			<frame marginheight="0" scrolling="yes" src="sample-
page.html" name="toc">
			<frame marginheight='0' scrolling="yes" src="sample-
page.html" name="results">
		</frameset>
		<frame marginheight="0" scrolling="no" src="sample-page.html" 
name="footer">
	</frameset>
</html>

- - - - -

Here's the filler page (sample-page.html):
- - - - -
<html>
	<head>
		<title>Sample Page</title>
	</head>
	<body>
		Sample Page
	</body>
</html>
- - - - -
Yes, I know having a <form> inside <head></head> tags violates the HTML spec.
There's another bug filed with the same problem, can't find that one.

And reporter, that DTD is wrong because it should be something like this:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"http://www.w3.org/TR/REC-html40/frameset.dtd">
note that we follow the spec, any deviation from it can make mozilla render
sites wierdly, especially with doctypes
The problem is most likely a parser problem.  We see a <form> and assume that
the <body> has started already....  over to parser.
Assignee: asa → harishd
Component: Browser-General → Parser
QA Contact: doronr → janc
Re: Additional Comments From H-J 2001-02-07 10:44
Found the bug this is a duplicate of.  It's bug #66985.  The only difference 
between the two seems to be that #66985 describes a <form> between </head> and 
<frameset>, while this one (#67994) describes a <form> between <head> and 
</head>.
I just tried editing the doctype in the test case I provided to reflect H-J's 
suggestion, and got a result that definitely counts as a bug, not just a busted 
HTML spec.  I'll be attaching a screenshot shortly.

    
    

    
  
Note that in the 0.7 release, the bits of browser don't appear in the window 
and the changed doctype seems to fix the problem.  Also, in the 2001020704 
build, the bits of browser that appear seems to vary a bit.

    
    

    
  
Nice Theo, you found that one, great. And you see, the same parser problem. I
call this rather a 'problem' then a 'bug' because it's not a bug at all, as you
might know. It's more like making mozilla 'foolproof'. I guess adding a keyword
to address this kind of issues can be helpfull.

A DTD is developed for an content model following the same W3C specs (and thats
clearly not the case for this document). As Doron wrote "we follow the specs"
and thats true, but I know that won't help you with this document. And as Boris
commented this is a parser issue, as for that other bug. 

Can't your find a way to make your frameset, the base of your site, at least to
be W3C compliant? Isn't there any other way to work around this problem? I don't
expect mozilla to run soon with this kind of documents, but I can be wrong.

    
    

    
  


  

    
    

    
  

      
      
      
      

        Attached file
          
        Filer page
        — 
      

    


  

    
    

    
  
WORKSFORME
platform: PC
OS: Linux 2.2.16
Mozilla Build: 2001021408

W/ the correct Doctype it works fine. Reporter try downloading one of the latest
nightlies and creating a new profile. See if that fixes the problem. Report back
either way :) Thanks in advance.
Keywords: testcase

    
    

    
  
Keyser, the reporter did try that DTD and attachment 24770 [details] shows the output. I
still think that if bug 66985 is fixed, then this bug might also be fixed. The
bug status for that other bug is 'assigned' so we have to wait on QA. Also note
that your attachments do not work on bugzilla, what should we do with them? Put
them on a local drive?

Janc@netscape.com must be:
A - a very busy person.
Or
B - he has left the building.

    
    

    
  

*** This bug has been marked as a duplicate of 66985 ***
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE

    
    

    
  
updated qa contact.
QA Contact: janc → bsharma

    
  
QA Contact: bsharma → moied

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: