If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

[DOCTYPE] should have stricter DOCTYPE parsing code

RESOLVED FIXED in mozilla0.9.5

Status

()

Core
HTML: Parser
P2
major
RESOLVED FIXED
18 years ago
16 years ago

People

(Reporter: dbaron, Assigned: dbaron)

Tracking

Trunk
mozilla0.9.5
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Hixie-P4])

Attachments

(2 attachments)

I'm entering this as a bug so that the code doesn't get lost, since I've pulled
it out of my tree.  I still think we should consider doing something like this
in the future, so I'm going to move this to MFuture.

The code I'm going to attach is a few functions (already slightly out of date)
that do mode selection based on strict parsing of the DOCTYPE.  They go to
noquirks for unknown DTD's from 3 sources (W3C, ISO, IETF), but quirks for
unknown ones from other sources.  What is done with a given set of DTDs could
easily be changed.  The parsing is done as close to the SGML spec as I could
get, although there are a few things I don't handle fully.
Keywords: patch
Target Milestone: --- → Future
Created attachment 10870 [details] [diff] [review]
the DOCTYPE parsing code itself
Created attachment 10871 [details] [diff] [review]
a diff for some other changes to use this code
Blocks: 34662

Comment 3

17 years ago
wont fix; pulling strictDTD support.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WONTFIX
Reopening.  We still use doctype parsing for layout quirks.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Marking [DOCTYPE] for easy searching.
Summary: should have stricter DOCTYPE parsing code → [DOCTYPE] should have stricter DOCTYPE parsing code
Nominating for mozilla 0.9.  I'd like to get this in (revised, due to
bug 55264) for mozilla 1.0, at it should have significant testing beforehand.

The current code is bad because it's just wrong.  We should be testing equality
of doctypes, not searching the DOCTYPE's public ID for certain strings such as
numbers that we think are versions or searching the system ID for certain
strings that are currently used as the file naming conventions for storage of
DTDs in W3C specs (e.g., "strict.dtd").  While it can be demonstrated to be
correct on many common examples, we've already seen one example of serious
failure (bug 55916), and there will probably be more.
Keywords: mozilla0.9
Blocks: 55916
For lack of comments from rickg, assigning to myself.
Assignee: rickg → dbaron
Severity: enhancement → major
Status: REOPENED → NEW
Priority: P3 → P1
Target Milestone: Future → mozilla0.9
Blocks: 61901
I've been trying to fix this in a sensible way involving only parsing the DOCTYPE
in one place.  However, the htmlparser design makes this very difficult.
Removing patch keyword based on dbaron's comments that the current patch is no 
longer valid. Good luck with getting this to work :-)

Gerv
Keywords: patch

Comment 10

17 years ago
updated qa contact.
QA Contact: janc → bsharma
Reality check.  Moving out to 0.9.1.
Target Milestone: mozilla0.9 → mozilla0.9.1
Target Milestone: mozilla0.9.1 → mozilla0.9.2
David: Do you still want to do something with this?
Whiteboard: [Hixie-P4]
*** Bug 82261 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
I would still like to do this, but 0.9.2 should be a low-risk milestone, so
moving to 0.9.3.  I guess we'll just ship 0.9.2 with the mess we currently have,
unless someone feels strongly that I should try to do this for 0.9.2.
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Priority: P1 → P2

Comment 15

16 years ago
what's the current status?
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Patch is incorporated into the patch on bug 55264.
Depends on: 55264
Fix checked in 2001-09-08 11:37 PDT (see bug 55264).

Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago16 years ago
Resolution: --- → FIXED

Updated

16 years ago
QA Contact: bsharma → moied
You need to log in before you can comment on or make changes to this bug.