71686 - DocumentType::GetEntities isn't implemented

Status: RESOLVED INVALID

Description

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

DocumentType::GetEntitites dosn't seem to be implemented in the XML DOM. 
Specificly I need to be able to get the SystemID of an unparsed entity to fix 
bug 65981. And IMHO the entities list is rather central thing since it's DOM L1 
Core...

Comment 1

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Created attachment 27454 [details]
small testcase

Comment 2

[Heikki Toivonen (remove -bugzilla when emailing directly)]

This is DOM 1, but very rarely used so it is not high on most people's priority.

I don't have time for this so it is all yours... And by the way, we haven't
implemented notations either so you might want to do them both at the same go,
they should be very similar.

I can review the fix for this bug, and I can get you started.

So, what you want to be looking at is nsExpatTokenixer, nsXMLContentSink and
maybe nsXMLDocument. The Expat parser gives us stuff we handle in the
nsExpatTokenizer. Place breakpoints there to learn how it works (make a simple
XML document that has the stuff you want to test, and remember that XUL also
uses this code path - so it might be best to use the viewer for debugging). The
sink then builds the content model from the tokens we create in the tokenizer.

Right now we don't do much with DTD stuff. Fox example, DOM Level 2 defines
property internalSubset on DocumentType and we support that. But is it simple,
just the whole DTD as text. We also support publicId and systemID. Once you
understand how this works, it should be pretty straight forward to implement the
entities and notations properties.

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

grmbl, that's not the response I wanted...

ok I'll look into this once some other transformiix issues are taken care of, 
but I can't promise anything even then, this is a bit more complicated then 
what i've done so far

Comment 4

[Prashant Desale]

Updating QA contact to Shivakiran Tummala.

Comment 5

[Alex Vincent [:WeirdAl]]

Lovely.

Comment 6

[Alex Vincent [:WeirdAl]]

Wait a sec... I can get the entities from document.doctype.internalSubset.  It's
there, just hasn't been split up.

I assume you don't want a JS-based patch :) but that's all I know how to do.

Comment 7

[Erick Fauquette]

I need this function to be compatible with ASD (ex AECMA) Spec 1000D  release 2.3) standard.

Because I need the function unparsed-entity-uri()

Or a way to workaround ...

Comment 8

[Alex Vincent [:WeirdAl]]

Wow, five and a half years since I last saw this bug.  Only now I'm a little stronger at C++...

My gut feeling says a proper fix might involve a lot of DOM hacking - basically, we'd have to implement the Entity and EntityReference objects for our DOM.  That in itself is no small task, and frankly I think it would need a lot of time - perhaps even a branch  - to do it right.  More significantly, it'd need someone willing to spend a time writing a patch.

As an example of the difficulties we would face, Verbosio currently emulates entity references through a bit of clever JavaScript.  But when you stick one of these custom entity refs inside a menupopup, you lose the vertical orientation...

Comment 9

[Erick Fauquette]

All happens ...

It's a lake that the function: string unparsed-entity-uri(string)described in the W3C recommendation doesn't work with Mozilla and works with IE ...

The problem is that there is no work around to retrieve the path of an image/picture file when you produce your xml file in conformance with DTD define by ASD 1000D spec.

In such case you have to use an expensive commercial publisher.

Comment 10

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

We dropped DocumentType.entities entirely.