[HTML5] <!doctype HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> should trigger the quirks mode

VERIFIED FIXED

Status

()

Core
HTML: Parser
--
major
VERIFIED FIXED
9 years ago
7 years ago

People

(Reporter: Jim Jeffery not reading bug-mail 1/2/11, Assigned: hsivonen)

Tracking

Trunk
x86
Windows NT
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments, 1 obsolete attachment)

Activate the HTML5 parser in about:config
Load the site in the URL 
Note the display is wrong and appears to be double-triple spaced or more
Turn off the HTML5 parser and reload the site to see the corrrect display of page.

This website also displays wrong with HTML5 enabled:
http://www.sandisk.com/Products/Catalog%281433%29-Players_bundles.aspx
(Assignee)

Comment 1

9 years ago
Activewin gets the standards mode with the HTML5 parser but needs the quirks mode.
(Assignee)

Comment 2

9 years ago
Sandisk spun off as bug 502804.
Summary: HTML5: Activewin display incorrect with HTML5 enabled → [HTML5] <!doctype HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> should trigger the quirks mode
(Assignee)

Updated

9 years ago
Assignee: nobody → hsivonen
(Assignee)

Comment 3

9 years ago
Created attachment 387174 [details] [diff] [review]
Use == instead of =

Sigh. A classic missing = bug introduced late in the landing review cycle.
Attachment #387174 - Flags: superreview?(mrbkap)
Attachment #387174 - Flags: review?(mrbkap)

Updated

9 years ago
Attachment #387174 - Flags: superreview?(mrbkap)
Attachment #387174 - Flags: superreview+
Attachment #387174 - Flags: review?(mrbkap)
Attachment #387174 - Flags: review+
(Assignee)

Comment 4

9 years ago
http://hg.mozilla.org/mozilla-central/rev/888b72291dfb

Thanks. Good catch.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Can we add a regression test for this?
Flags: in-testsuite?
Verified fixed using hourly build:

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090708 Minefield/3.6a1pre Firefox/3.0.11 ID:20090708023540

changeset:
http://hg.mozilla.org/mozilla-central/rev/845fd6b1ef23

ActiveWin is now looking normal again. Thanks.
Status: RESOLVED → VERIFIED
Created attachment 391713 [details] [diff] [review]
mochitest test case

I've added this case to test_compatmode.html.  I've also modified that test to run all tests twice:  once without html5.enabled and once with.
Attachment #391713 - Flags: review?(hsivonen)
(Assignee)

Comment 8

9 years ago
Comment on attachment 391713 [details] [diff] [review]
mochitest test case

I think it would be easier to follow what the test is doing if running two times were explicit two lines like

doTestWithoutHtml5();
doTestWithHtml5();

instead of the tail of the first run triggering the second run.

Is there a reason for doing it this way?
Created attachment 392744 [details] [diff] [review]
mochitest test case

I've added some comments to the make the test more readable.

I don't think I can structure the test like so:
doTestWithoutHtml5();
doTestWithHtml5();

This is because the test isn't synchronous.  The verification takes place in the iframe's onload handler, and we can't be sure exactly when that will be fired.  If we called the doTest() functions consecutively, there's a chance that the doTestWithHtml5() function would enable the HTML5 parser before the last test in the previous test had completed, or such is my understanding.
Attachment #391713 - Attachment is obsolete: true
Attachment #392744 - Flags: review?(hsivonen)
Attachment #391713 - Flags: review?(hsivonen)
(Assignee)

Comment 10

9 years ago
Comment on attachment 392744 [details] [diff] [review]
mochitest test case

OK. I now realize why the the tail of the first run needs to trigger the next run. Please ask someone with a better understanding of the test conventions to sr, though, please.
Attachment #392744 - Flags: review?(hsivonen) → review+
(Assignee)

Comment 11

9 years ago
(That is, I don't have proper experience of writing mochitests, so I'm not confident that this is the way it needs to be, even though I now see why it is the way it is.)
Comment on attachment 392744 [details] [diff] [review]
mochitest test case

Bz, can you sr this test per Henri's comments?
Attachment #392744 - Flags: superreview?(bzbarsky)
Attachment #392744 - Flags: superreview?(bzbarsky) → superreview+
Comment on attachment 392744 [details] [diff] [review]
mochitest test case

Looks ok if we don't do the second pass if html5 parser was enabled during the first pass.  That way we won't be doing two redundant passes once the html5 parser is on by default...

Alternately, file a followup bug on removing the html5 part of things once that parser is on by default?
Depends on: 508867
I opted for option #2 in comment #13; see bug 508867.
Pushed test as http://hg.mozilla.org/mozilla-central/rev/f911882ac419
Flags: in-testsuite? → in-testsuite+
(Assignee)

Updated

8 years ago
Blocks: 508867
No longer depends on: 508867

Updated

7 years ago
Depends on: 601425
You need to log in before you can comment on or make changes to this bug.