Closed Bug 606996 Opened 14 years ago Closed 14 years ago

Reordering of Script breaks page

Categories

(Core :: DOM: HTML Parser, defect)

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

Tracking

()

Status:
RESOLVED DUPLICATE of bug 178258

People

(Reporter: marc, Unassigned)

Details

User-Agent:       Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET CLR 1.1.4322; InfoPath.2; MS-RTC LM 8)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10 ( .NET CLR 3.5.30729)

The following excerpt was taken from an IFRAME on www.samsung.com.


<form name="repairForm" method="post">
<input type="hidden" name="session_id" value="testing">
<input type="hidden" name="email" value="null">
<input type="hidden" name="bp_no" value="null">
<input type="hidden" name="from" value="">
<input type="hidden" name="lang" value="us">
</form>
<script language="javascript">
document.repairForm.action = "http://support-cacyber.samsung.com/cacyber/product_information.jsp?lang=us";
document.repairForm.submit();
</script>

On IE, the page renders correctly, but FF only displays a blank page.  Debugging with Firebug I notice a console error for an undefined object. Further inspection revealed that an IFRAME was loading a page with invalid HTML markup (missing HTML and HEAD tags). It contained a form element followed by a script element that was accessing the form. I then examined the rendered HTML and saw that Firefox had added the missing tag elements and moved the script element into the head, thereby moving it outside of document order. The same page in IE renders correctly, and inspecting the results there show that document order is being preserved. I realize that browser behavior is likely undefined for poorly non-compliant html; however, I would expect parser to preserve document order of the elements. I've examined the parser code, and DoesRequireBody() function in CNavDTD.cpp prevents INPUT elements that don't have type attribute or are hidden to trigger BODY to be created and can lead to following scripts to be moved up to HEAD and taken out of order.  Why is this check being done?  Also, why isn't FORM element tagged with requiresbody bitflag and only its containing INPUT elements?  As soon as any element that cannot be in the HEAD is parsed from the token deque shouldn't that trigger BODY?

Reproducible: Always
Marc, thanks for investigating this and reporting it.  This problem is fixed in the new HTML5 parser in Firefox 4.  

> As soon as any element that cannot be in the HEAD is parsed from the token
> deque shouldn't that trigger BODY?

I _think_ that's what happens in the HTML5 parser.  I'm not sure, though.  It's certainly not what IE does; see bug 178258 comment 30.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
Oh, and the CNavDTD checks for hidden inputs were there because people put them before <frameset> tags, and if they implied <body> then the <frameset> would be ignored due to a <body> already being open...
Thank you Boris.  Can I assume then that this won't be fixed in 3.x?  I've also contacted Samsung to have them fix the page in question.  Part of the problem is that the onus should be on website developers to ensure that their html is compliant to spec.  Over time browser designers have tried to compensate by fixing up incomplete/bad markup, but there are simply so many edge cases that sometimes leads to more problems than it solves and the root causes are never corrected.

Also, may I PM you? I had a few additional questions on parser component's origins and how it has evolved to latest incarnation in FF4.
>  Can I assume then that this won't be fixed in 3.x? 

Yeah.  We're not going to mess with the parser on the stable branch...

> Also, may I PM you?

Absolutely.  e-mail to my bugzilla email address should work just fine.
(In reply to comment #3)
> I had a few additional questions on parser component's
> origins and how it has evolved to latest incarnation in FF4.

The HTML parser in Firefox 4 hasn't really evolved from what's in Firefox 3.6. Firefox 4 has a new HTML parser that's written from scratch to be HTML5-compliant.
You need to log in before you can comment on or make changes to this bug.