Last Comment Bug 178258 - HTML parser ships <script> to implicit <head>, breaking document.forms or document.getElementById
: HTML parser ships <script> to implicit <head>, breaking document.forms or doc...
Status: RESOLVED FIXED
[fixed by the HTML5 parser]
: html5, testcase
Product: Core
Classification: Components
Component: HTML: Parser (show other bugs)
: Trunk
: All All
: P2 normal with 16 votes (vote)
: mozilla1.9.3a5
Assigned To: Nobody; OK to take it and work on it
:
: Andrew Overholt [:overholt]
Mentors:
http://www.azur.be/
: 153542 178773 181526 185438 211489 224619 227798 229164 233745 300644 309469 324262 343808 363899 367544 402537 421153 494558 530344 606996 (view as bug list)
Depends on: html5-parsing
Blocks: 239182 acid3 549490
  Show dependency treegraph
 
Reported: 2002-11-04 00:57 PST by Guy Geens
Modified: 2010-10-25 12:16 PDT (History)
69 users (show)
chofmann: blocking‑aviary1.0-
jst: blocking1.9.2-
jst: blocking1.9.1-
jst: wanted1.9.1+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Reduced testcase without body tag (106 bytes, text/html)
2002-12-16 16:26 PST, Phil Schwartau
no flags Details
Reduced testcase with body tag (123 bytes, text/html)
2002-12-16 16:29 PST, Phil Schwartau
no flags Details
patch that doesn't work (2.34 KB, patch)
2008-09-17 13:44 PDT, David Baron :dbaron: ⌚️UTC-10
no flags Details | Diff | Splinter Review
Like so? (3.69 KB, patch)
2008-09-17 19:16 PDT, Mats Palmgren (:mats)
no flags Details | Diff | Splinter Review

Description Guy Geens 2002-11-04 00:57:03 PST
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826

In the checkout process, the site uses a short "forwarding" page. The page
contains a hidden form and some Javascript to relay the user to the next step.

This mechanism works on IE, but fails on Mozilla (1.0 and 1.1).

Reproducible: Always

Steps to Reproduce:
1. Go to http://www.azur.be/
2. Select one or more articles from the catalog
3. Go to the checkout page. This will prompt you to create a profile.
4. Select a payment type.
Actual Results:  
Mozilla shows a blank page. The Javascript console contains the error:
document.form1 has no properties. (The page source is included below.)

Expected Results:  
Submit the form and continue with the next step in the checkout process.

Page source:
<form action="/secure/order/order_purchase_overschr.asp" method=post id=form1
name=form1>
	
	<input type=hidden name="kortingo" value="">
	<input type=hidden name="korting" value="">
	<input type=hidden name="return_shop" value="">
	<input type=hidden name="preOrderReduceNote" value="">
	<input type=hidden name="betwijze" value="over">
	<input type=hidden name="VoucherCode" value="">
</form>

<script language="Javascript">
	document.form1.submit();
</SCRIPT>
Comment 1 Guy Geens 2002-12-04 03:01:32 PST
The site has closed down. It doesn't make sense to keep it as a Tech Evangelism bug.

I'm reassigning this to Browser: the page from my original bug report should
post the form, but it doesn't. (This is different from the document.all
construct IMHO.)
Comment 2 Phil Schwartau 2002-12-16 16:24:11 PST
Browser, not engine ---> Parser for further triage.

Using Mozilla trunk binary 20021204xx on WinNT. I'll attach
two reduced testcases below, showing why we get the error

            "document.form1 has no properties"


------------------------- Testcase #1 -------------------------
<form id=form1 name=form1></form>

<script>
  alert('document.form1 is: ' + document.form1);
</SCRIPT>
---------------------------------------------------------------

------------------------- Testcase #2 -------------------------
<body>
<form id=form1 name=form1></form>
</body>

<script>
  alert('document.form1 is: ' + document.form1);
</SCRIPT>
---------------------------------------------------------------

Note the only difference is that testcase #2 has a body element,
while testcase #1 doesn't.


--------------------------- OUTPUT ----------------------------

Mozilla: testcase #1 produces 'undefined'
         testcase #2 produces '[object HTMLFormElement]'

IE6: both testcases produced: '[object]'
NN4: both testcases produced: '[object Form]'


So it seems that Mozilla needs the form to be inside the body element
in order to recognize it. I leave it to the Parser folks to comment
on whether this is a bug or not. Certainly it is not backward-compatible
with NN4.
Comment 3 Phil Schwartau 2002-12-16 16:26:38 PST
Created attachment 109480 [details]
Reduced testcase without body tag
Comment 4 Phil Schwartau 2002-12-16 16:29:09 PST
Created attachment 109481 [details]
Reduced testcase with body tag
Comment 5 HARUNAGA Hirotoshi 2003-07-19 05:06:26 PDT
Changing to All and Trunk.
Old summary:
Javascript error: document.form1 has no properties
New summary:
document.forms has no properties on a page without <body> (JavaScript error)

Related bugs are bug 144780 and bug 185438.
Comment 6 Andrew Schultz 2003-07-20 06:17:52 PDT
*** Bug 185438 has been marked as a duplicate of this bug. ***
Comment 7 HARUNAGA Hirotoshi 2003-07-21 00:25:30 PDT
*** Bug 178773 has been marked as a duplicate of this bug. ***
Comment 8 Derek Schrock 2003-11-07 19:25:54 PST
*** Bug 224619 has been marked as a duplicate of this bug. ***
Comment 9 Mats Palmgren (:mats) 2003-12-08 06:14:36 PST
*** Bug 227798 has been marked as a duplicate of this bug. ***
Comment 10 Boris Zbarsky [:bz] (still a bit busy) 2003-12-08 09:33:48 PST
*** Bug 153542 has been marked as a duplicate of this bug. ***
Comment 11 Boris Zbarsky [:bz] (still a bit busy) 2003-12-08 09:34:18 PST
From bug 153542:

It looks like the parser has explicit code to handle the following case:

  If we have not seen a <body> tag and we see a <script> tag, move that <script>
  tag over under the <head> tag.

In the process, the <script> is actually appended to the document _before_ the
<form> is, which causes all sorts of fun stuff to happen.  See
CNavDTD::HandleStartToken

I suspect that code is there for a reason, and that removing or changing it
should not be undertaken lightly...
Comment 12 Malcolm Rowe 2003-12-22 05:12:50 PST
*** Bug 229164 has been marked as a duplicate of this bug. ***
Comment 13 Mats Palmgren (:mats) 2004-02-10 16:13:47 PST
*** Bug 181526 has been marked as a duplicate of this bug. ***
Comment 14 Boris Zbarsky [:bz] (still a bit busy) 2004-02-10 16:17:34 PST
*** Bug 233745 has been marked as a duplicate of this bug. ***
Comment 15 Hixie (not reading bugmail) 2004-02-12 07:40:43 PST
Some of these testcase work in IE, but others do the same in IE as Mozilla. 
Opera seems to reliably put the elements in the document in the order they are 
found, but that might be a backcompat bug.
Comment 16 Boris Zbarsky [:bz] (still a bit busy) 2004-02-12 08:45:02 PST
Could you tell me which of these work in IE and on which IE acts like Mozilla?
Comment 17 Hixie (not reading bugmail) 2004-02-12 09:25:22 PST
Browsers tested:
   Opera 7.50 internal pre-release build on Windows 2000.
   Mozilla Firefox 0.8 official build on Windows 2000.
   Internet Explorer 6.1 preview release on Windows 2000.

http://bugzilla.mozilla.org/attachment.cgi?id=107176&action=view
Objects accessible in all three browsers.

http://off.net/~shaver/gebi.html
Object accessible in Opera, null in IE and Mozilla.

http://bugzilla.mozilla.org/attachment.cgi?id=109480&action=view
Object accessible in Opera and IE, undefined in Mozilla.

http://bugzilla.mozilla.org/attachment.cgi?id=88761&action=view
Opera and IE show "test1" then "test2". Mozilla first shows "has no properties" 
and then "test2".

http://bugzilla.mozilla.org/attachment.cgi?id=88763&action=view
All three show "test1" followed by "test2".

http://bugzilla.mozilla.org/attachment.cgi?id=105403&action=view
Accessible in all three browsers.

http://66.54.199.11/~netchess/bug.html
Shows "Testing" in Opera and IE, nothing in Mozilla.

http://bugzilla.mozilla.org/attachment.cgi?id=109344&action=view
Object accessible in Opera and IE, undefined in Mozilla.

HTH.
Comment 18 Boris Zbarsky [:bz] (still a bit busy) 2004-02-20 01:06:37 PST
*** Bug 211489 has been marked as a duplicate of this bug. ***
Comment 19 Boris Zbarsky [:bz] (still a bit busy) 2004-03-30 16:49:04 PST
OK, so it looks like <div> does not prevent the <script> from moving into <head>
in IE, but <form> does.  Any other such magic HTML tags that keep IE from moving
the <script> into the head if they appear before the <script> (and do they need
to contain the <script>, or can they be closed before the <script>?)
Comment 20 Asa Dotzler [:asa] 2004-09-21 11:10:40 PDT
We've got a reduced testcase and quite a few dupes. Who can look into this?
Comment 21 Boris Zbarsky [:bz] (still a bit busy) 2004-09-21 11:32:55 PDT
We need some comprehensive testcases to answer the question in comment 19. 
Sounds like a good QA exercise to me... we have some of those around, right?
Comment 22 chris hofmann 2004-09-30 17:12:15 PDT
if we get close to a safe patch renominate.  thanks...
Comment 23 anita.kessler 2004-10-19 10:00:43 PDT
Strange enough document.forms HAS properties if the form contains an <input
type=text> or <input type=submit> although there is no <body> tag!

Works, as there is <body>:

<html>
<body>
<form name="form"><select name="sel"><option></select></form>
<script>alert(document.form.sel.options.length);</script>
</body>
</html>

Does not work (Error: document.form has no properties):

<html>
<form name="form"><select name="sel"><option></select></form>
<script>alert(document.form.sel.options.length);</script>
</html>

And this again DOES work, also with a input type=text, WITHOUT <body>:

<html>
<form name="form"><select name="sel"><option></select><input type=submit></form>
<script>alert(document.form.sel.options.length);</script>
</html>
Comment 24 Jesse Ruderman 2004-10-22 01:36:03 PDT
This bug breaks the freeipods.com signup process.
Comment 25 Elmar Ludwig 2005-07-14 03:53:39 PDT
*** Bug 300644 has been marked as a duplicate of this bug. ***
Comment 26 Philip Puryear 2006-01-22 22:54:35 PST
*** Bug 324262 has been marked as a duplicate of this bug. ***
Comment 27 Boris Zbarsky [:bz] (still a bit busy) 2006-04-10 14:23:18 PDT
*** Bug 309469 has been marked as a duplicate of this bug. ***
Comment 28 Smokey Ardisson (offline for a while; not following bugs - do not email) 2006-07-07 22:08:27 PDT
*** Bug 343808 has been marked as a duplicate of this bug. ***
Comment 29 Mats Palmgren (:mats) 2006-12-17 04:06:26 PST
*** Bug 363899 has been marked as a duplicate of this bug. ***
Comment 30 Phil Ringnalda (:philor) 2006-12-31 01:59:11 PST
> Sounds like a good QA exercise to me... we have some of those around, right?

bz, please remember that you *did* ask, and the whole don't kill the messenger thing.

Assuming shaver's gebi.html is what you wanted tested, and that http://www.w3.org/TR/html4/index/elements.html is a complete list of elements, in IE6, with an empty <element id="myid"></element>:

Return [Object]:
abbr, applet, area, base, basefont, body, br, button, caption, col, colgroup, dd, dt, form, frame, head, hr, html, iframe, img, input, isindex, legend, li, link, map, meta, noframes, noscript, object, optgroup, option, param, pre, script, select, style, table, tbody, td, textarea, tfoot, th, thead, title, tr

Return null:
a, acronym, address, b, bdo, big, blockquote, center, cite, code, del, dfn, dir, div, dl, em, fieldset, font, h1, h2, h3, h4, h5, h6, i, ins, kbd, label, menu, ol, p, q, s, samp, small, span, strike, strong, sub, sup, tt, u, ul, var

I didn't figure out how to test frameset.

In every case (except frameset), <element id="myid">foo</element> returns [Object], other than the rather odd case of <object id="myid">foo</object> returning null. I assume an object that wasn't rendering fallback content wouldn't, but I didn't test that.

> (and do they need to contain the <script>, or can they be closed before
> the <script>?)

Makes no difference: the results are exactly the same with <element><script></script></element> as they are with <element></element><script></script>.
Comment 31 Anne (:annevk) 2006-12-31 05:05:54 PST
Note that HTML5 defines that <script> is no longer moved to the <head> in these cases. (Similar to what Opera does. FWIW, it doesn't appear to break pages for us.) 
Comment 32 Mats Palmgren (:mats) 2007-01-20 05:56:25 PST
*** Bug 367544 has been marked as a duplicate of this bug. ***
Comment 33 Boris Zbarsky [:bz] (still a bit busy) 2007-08-13 21:03:16 PDT
Hmm.  Maybe we should in fact just stop shipping out scripts to the head...
Comment 34 Phil Ringnalda (:philor) 2007-11-05 21:18:43 PST
*** Bug 402537 has been marked as a duplicate of this bug. ***
Comment 35 Jesse Ruderman 2008-03-05 13:10:32 PST
*** Bug 421153 has been marked as a duplicate of this bug. ***
Comment 36 Daniel.S 2008-08-08 10:44:02 PDT
Nominating because it seems like a win-win situation. The fix would help HTML5, Acid3 and reduce the number of dupes filed.
Comment 37 David Baron :dbaron: ⌚️UTC-10 2008-09-17 13:44:14 PDT
Created attachment 339125 [details] [diff] [review]
patch that doesn't work

I sort of thought this would fix the Acid3 example of this bug, but it doesn't.

At lunch, mrbkap made it sound (at lunch) like it would be more involved than this to fix this bug (by not shipping scripts to the head), although he (just now) seemed a little surprised that this didn't work.
Comment 38 David Baron :dbaron: ⌚️UTC-10 2008-09-17 13:52:48 PDT
mrbkap pointed out that script doesn't "prefer body", which is why the patch doesn't fix Acid3.

He also pointed out that we should probably look at the list in comment 30 and at what, exactly, HTML5 says to do.
Comment 39 Mats Palmgren (:mats) 2008-09-17 19:16:28 PDT
Created attachment 339167 [details] [diff] [review]
Like so?

This seems to fix it.  It passes mochitests with the exception of
parser/htmlparser/tests/mochitest/test_bug418464.html
which appears to depend on this bug, so I changed the test.

It also passes the parser html regession tests with the exception of
parser/htmlparser/tests/html/149877.html
where we currently move the last <script> into HEAD, but with this patch
it remains in BODY (the first <script> is still moved to HEAD).
I believe the new parsing is correct and it doesn't affect the
end result of the test which still reads "should see this content".

Acid3: I get 86 before, 87 after the patch.
Comment 40 David Baron :dbaron: ⌚️UTC-10 2008-09-20 20:20:06 PDT
Mats, did you want to ask mrbkap for review?
Comment 41 Tomas 2008-10-15 06:37:32 PDT
Any decision or progress on that?
Comment 42 Tom Levels 2009-04-08 06:16:04 PDT
Any update on the review of the patch?
Comment 43 Michael 2009-05-04 12:13:47 PDT
Update plx
Comment 44 Dão Gottwald [:dao] 2009-05-23 05:27:49 PDT
*** Bug 494558 has been marked as a duplicate of this bug. ***
Comment 45 Bill Gianopoulos [:WG9s] 2009-06-30 04:35:24 PDT
(In reply to comment #39)
> Created an attachment (id=339167) [details]
> Like so?
> 
> This seems to fix it.  It passes mochitests with the exception of
> parser/htmlparser/tests/mochitest/test_bug418464.html
> which appears to depend on this bug, so I changed the test.
> 
> It also passes the parser html regession tests with the exception of
> parser/htmlparser/tests/html/149877.html
> where we currently move the last <script> into HEAD, but with this patch
> it remains in BODY (the first <script> is still moved to HEAD).
> I believe the new parsing is correct and it doesn't affect the
> end result of the test which still reads "should see this content".

This patch only fixes the issue if html5.enable is set to false.
Comment 46 Bill Gianopoulos [:WG9s] 2009-06-30 05:23:34 PDT
(In reply to comment #45)
> This patch only fixes the issue if html5.enable is set to false.

I filed bug 501345 on the html5 parser issue.
Comment 47 Johnny Stenback (:jst, jst@mozilla.com) 2009-07-22 17:45:37 PDT
Not blocking 1.9.2 on this. Ideally we'd only need to fix this with the HTML5 parser and not in the current parser...
Comment 48 Boris Zbarsky [:bz] (still a bit busy) 2009-12-02 21:19:08 PST
*** Bug 530344 has been marked as a duplicate of this bug. ***
Comment 49 Jean-Marc Desperrier 2010-02-25 01:26:10 PST
Could we nominate this again for 1.9.3 ?
Comment 50 Boris Zbarsky [:bz] (still a bit busy) 2010-02-25 08:02:39 PST
The plan for 1.9.3 is to ship the html5 parser.
Comment 51 Bill Gianopoulos [:WG9s] 2010-05-03 08:10:55 PDT
Now that the HTML5 parser is enabled by default, should this be WONTFIXed?
Comment 52 Dão Gottwald [:dao] 2010-05-03 08:12:59 PDT
The HTML5 parser fixed it, didn't it? If so, this should be resolved as fixed.
Comment 53 Boris Zbarsky [:bz] (still a bit busy) 2010-05-03 08:41:31 PDT
Note that this depends on the html5 parser tracking bug.  Once it's decided that it has been enabled and sticks, we should probably go through those deps and mark fixed as needed.

Though we're still using our old parser for some things so far; not sure whether it matters for this bug.
Comment 54 Bill Gianopoulos [:WG9s] 2010-05-03 16:32:34 PDT
(In reply to comment #52)
> The HTML5 parser fixed it, didn't it? If so, this should be resolved as fixed

It would seem you are correct.  Silly me was thinking not fixing in old parser so WONTFIX, but since landing of the HTML5 parser and enabling it by default fixes the bug as described, it would seem that FIXED is the correct resolution here.
Comment 55 José Jeria 2010-05-04 07:05:14 PDT
HTML5 Parser has been re-enabled, this should be marked as FIXED
Comment 56 Boris Zbarsky [:bz] (still a bit busy) 2010-10-25 12:16:07 PDT
*** Bug 606996 has been marked as a duplicate of this bug. ***

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