Closed Bug 418464 Opened 17 years ago Closed 17 years ago

[FIX]Site (http://www.amherst.umassonline.net/index.cfm) is not rendered properly

Categories

(Core :: DOM: Core & HTML, defect, P2)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: wpanther, Assigned: bzbarsky)

References

(
URL
)

Details

(Keywords: regression)

Attachments

(1 file)

OK, let's do it
6.80 KB, patch
mrbkap
: review+
mrbkap
: superreview+
sicking
: approval1.9+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; ru; rv:1.9b3) Gecko/2008020511 Firefox/3.0b3 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; ru; rv:1.9b3) Gecko/2008020511 Firefox/3.0b3 Go to http://www.amherst.umassonline.net/index.cfm and observe only set of text links instead of the page. Reproducible: Always Steps to Reproduce: 1. Go to http://www.amherst.umassonline.net/index.cfm 2. 3. Actual Results: Bunch of text links only: Printer Friendly | E-mail this page Copyright Compliance | Privacy Policy | Site Map | Contact Us | This is an official page/publication of the University of Massachusetts. ©2007 University of Massachusetts. UMass Amherst | UMass Boston | UMass Dartmouth | UMass Lowell | UMass Worcester | UMass Club | UMass System This page last updated on December 21, 2007. Expected Results: Fully rendered page
Looks indeed weird (using latest trunk on Windows XP). Error: document.formGo is undefined Source File: http://www.amherst.umassonline.net/index.cfm Line: 41
Regression range is http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1196648460&maxdate=1196649539 with only one bug in it: Bug 390565
Blocks: 390565
Status: UNCONFIRMED → NEW
Component: General → DOM: HTML
Ever confirmed: true
Keywords: regression
OS: Mac OS X → All
Product: Firefox → Core
QA Contact: general → general
Hardware: Macintosh → All
Version: unspecified → Trunk
Gah. The relevant part, all before the <head> or <body> or anything is: <form name="formGo" action="index.cfm" method="post"> <input type="Hidden" name="mode" value="begin"> </form> <script> document.formGo.submit(); </script> Now we ship out the <script> to the synthetic <head>, so it runs before the <form> has been put in the DOM. Before bug 390565 we used to require a <body> for anything that wasn't type="hidden" or type="HIDDEN" (case-sensitive check). Now we (correctly, really) do a case-insensitive check and no longer require a body for that <input>. Blake, thoughts? I could undo the DoesRequireBody() check. Or we could start requiring the body for <form>. Or we could stop shipping out <script>... Any other ideas? What should we do for 1.9?
Component: DOM: HTML → HTML: Parser
Flags: blocking1.9?
QA Contact: general → parser
Component: HTML: Parser → DOM: HTML
Flags: tracking1.9? → blocking1.9?
Flags: blocking1.9?
Flags: blocking1.9?
I guess the safest thing to do here would be to just undo the DoesRequireBody check :-/. Everything else scares me.
Attached patch OK, let's do it — — Splinter Review
The way this function handles <input> and <input type="text"> different sets my teeth on edge... but whatever.
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Attachment #306971 - Flags: superreview?(mrbkap)
Attachment #306971 - Flags: review?(mrbkap)
Summary: Site (http://www.amherst.umassonline.net/index.cfm) is not rendered properly → [FIX]Site (http://www.amherst.umassonline.net/index.cfm) is not rendered properly
Comment on attachment 306971 [details] [diff] [review] OK, let's do it I guess there are existing bugs on not shipping script out.
Attachment #306971 - Flags: superreview?(mrbkap)
Attachment #306971 - Flags: superreview+
Attachment #306971 - Flags: review?(mrbkap)
Attachment #306971 - Flags: review+
Comment on attachment 306971 [details] [diff] [review] OK, let's do it regressions.txt test will need changing, but the other test should still be ok. Requesting approval. This just restores the code we used to have in 1.8 in this one case, so should be pretty safe and improves our compat...
Attachment #306971 - Flags: approval1.9?
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
verified fixed using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008050804 Minefield/3.0pre and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008050614 Minefield/3.0pre
Status: RESOLVED → VERIFIED
Component: DOM: HTML → DOM: Core & HTML
QA Contact: parser → general
The site that this bug was reported about has changed. The test case http://mxr.mozilla.org/mozilla-central/source/parser/htmlparser/tests/mochitest/test_bug418464.html expects the first script to fail to find a form. With the HTML5 parser (bug 547685), both forms and scripts end up in <body> in their original source order, so scripts find a form. Is making the first script fail really desirable and something the test needs to assert?
I would be fine with reverting the test here. We know some things will change with the HTML5 parser, but I think we should stick with it unless until we get feedback about real-world breakage which can't be evangelized.
> Is making the first script fail really desirable and something the test needs > to assert? I don't think so. Flipping it to assert that both are available makes sense to me, now that we can expect that to be the case.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: