Closed Bug 237855 Opened 21 years ago Closed 21 years ago

Mozilla doesn't recognise MathML 2.0 DOCTYPE and DTD and chokes on its entities

Categories

(Core :: MathML, defect)

Product:
Core
Component:
MathML
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: alexeyc2003, Assigned: alexeyc2003)

References

(
URL
)

Details

Attachments

(3 files, 1 obsolete file)

testcase
17.32 KB, text/xml
Details
patch v1.1
2.41 KB, patch
rbs
: review-
Details | Diff | Splinter Review
patch v1.01
955 bytes, patch
rbs
: review+
jst
: superreview+
dbaron
: approval1.7+
Details | Diff | Splinter Review
Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.7b) Gecko/20040317 When trying to open a document with a proper MathML 2.0 doctype: <!DOCTYPE math PUBLIC "-//W3C//DTD MathML 2.0//EN" "http://www.w3.org/Math/DTD/mathml2/mathml2.dtd"> Mozilla fails to parse it, because doesn't recognise the entities. Hoever the entities *are* present in Mozillas internal mathml.dtd, and when the doctype is changed to include XHTML: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1 plus MathML 2.0//EN" "http://www.w3.org/Math/DTD/mathml2/xhtml-math11-f.dtd"> the document gets parsed fine.
Attached file testcase —
The markup for this testcase document was taken from Mozillas MathML Basics demo: http://www.mozilla.org/projects/mathml/demo/basics.xhtml
Attached patch patch (obsolete) — — Splinter Review
Assignee: rbs → alexey
Status: NEW → ASSIGNED
Attachment #144195 - Flags: review?(rbs)
Comment on attachment 144195 [details] [diff] [review] patch ok, I was just thinking that perhaps the MathML and SVG items should be #ifdefed there. With pure MathML and SVG it's simple, but what about combinations? XHTML + MathML and XHTML + MathML + SVG profiles? If they are to be ifdefed, then how? How can we let Mozilla try to render a mixed document with the modules it has it has compiled in, while removing unnessesary lines for mobile applications?
Comment on attachment 144195 [details] [diff] [review] patch Tip to attract quick reviews: don't bother reformating since what you are adding isn't changing the table. Otherwise you might scare away your potential r/sr.
Attached patch patch v1.1 — — Splinter Review
put ifdefs in for MathML and SVG
Attachment #144195 - Attachment is obsolete: true
Attachment #144195 - Flags: review?(rbs)
Attachment #144329 - Flags: review?(rbs)
Comment on attachment 144329 [details] [diff] [review] patch v1.1 don't ifdef, don't re-ident (seem that you don't hear what is being said)
Attachment #144329 - Flags: review?(rbs) → review-
I don't understand what's wrong with ifdefing?
- It maybe that the document is being parsed as data (i.e., not rendering - think web-services -- the DOMParser in xmlextras for example). - It maybe that there is no <math> fragment at all in the document. - It maybe that the author styled it with "math {display: none}" or something (e.g., XSLT). - It maybe that the author has a disclaimer, e.g., "needs a MathML-enabled build" -- from where at least the user can figure out what to do. With a fatal parser error, the clueless user doesn't even have a chance to move on. So on the whole, it is not worth the hassle. There might be more to lose with #ifdef'ing than to gain. What we gain is nearly zarro bytes of memory to declare these doctypes, who cares. [You might be interested in bug 109825.]
OS: Windows Server 2003 → All
Hardware: PC → All
You are assuming that mathml.dtd is present in the build that has MathML disabled, which I think is not very likely. If someone is embedding Mozilla without MathML, I don't think they will want to include a 64KiB mathml.dtd and 13KiB of mathml.css. Especially in a project like Minimo. In my patch I did what's best for when mathml.dtd is missing, and improving it's chances of rendering the document hosted in XHTML. What we lose on MathML disabled builds: * Potentially (document might not have any MathML entities after all) ability to parse content containing MathML. What we gain on MathML disabled builds: * Retaining full XHTML support for XHTML documents that contain MathML * 121 bytes of memory. * CPU cycles it takes to process and parse that table If mathml.dtd is missing in MathML disabled buld, the patch brings only gain and no losses.
Attached patch patch v1.01 — — Splinter Review
minimalistic patch
Comment on attachment 144460 [details] [diff] [review] patch v1.01 That's better. r=rbs mathml.{dtd,css} are not present in MathML-disabled builds. The only extras are those declarations (121bytes per your count). No need to waste time checking the sizes of the .dtd/.css files for argument sake. Just patch with the intended doctype, as in Rome. There is always room for (non-premature) iterations.
Attachment #144460 - Flags: review+
Attachment #144460 - Flags: superreview?(jst)
Comment on attachment 144460 [details] [diff] [review] patch v1.01 sr=jst
Attachment #144460 - Flags: superreview?(jst) → superreview+
Attachment #144460 - Flags: approval1.7?
Checked in and applied to both: /htmlparser/ and /parser/htmlparser/ The latest nightlies should contain the fix.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: