Closed
Bug 840401
Opened 13 years ago
Closed 8 years ago
Remove nsIDOMDocumentType
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
DUPLICATE
of bug 1445140
People
(Reporter: dzbarsky, Assigned: dzbarsky)
References
Details
Attachments
(1 file)
|
48.19 KB,
patch
|
Ms2ger
:
review+
smaug
:
superreview-
|
Details | Diff | Splinter Review |
No description provided.
| Assignee | ||
Comment 1•13 years ago
|
||
Attachment #712770 -
Flags: review?(Ms2ger)
Comment 2•13 years ago
|
||
Tiny bit risky stuff. If dtd is removed, how is a binary addon supposed to create for example
SVG document safely?
| Assignee | ||
Comment 3•13 years ago
|
||
I'm not sure I understand what you're asking. Why can't addons do the same thing they currently do, but use mozilla::dom::DocumentType instead of nsIDOMDocumentType?
But I did just check addons, and it looks like two of them use Components.interfaces.nsIDOMDocumentType
Comment 4•13 years ago
|
||
Because WebIDL stuff is mostly non-virtual and not properly exposed outside libxul.
Comment 5•13 years ago
|
||
Comment on attachment 712770 [details] [diff] [review]
Patch
Review of attachment 712770 [details] [diff] [review]:
-----------------------------------------------------------------
::: accessible/src/generic/DocAccessible.cpp
@@ +381,5 @@
> nsCOMPtr<nsIXULDocument> xulDoc(do_QueryInterface(mDocumentNode));
> if (xulDoc) {
> aDocType.AssignLiteral("window"); // doctype not implemented for XUL at time of writing - causes assertion
> return NS_OK;
> } else
Please get rid of this else while you're here
@@ +384,5 @@
> return NS_OK;
> } else
> #endif
> + if (doc) {
> + doc->GetDoctype()->GetPublicId(aDocType);
GetDoctype() can return null
::: content/base/src/nsDocument.cpp
@@ +4500,3 @@
> {
> MOZ_ASSERT(aDoctype);
> + nsCOMPtr<nsISupports> doctype = static_cast<nsINode*>(nsIDocument::GetDoctype());
Can you try just making this
nsCOMPtr<nsINode> doctype = nsIDocument::GetDoctype();
?
::: content/base/src/nsGenericDOMDataNode.cpp
@@ +8,1 @@
> * nsIDOMCDATASection, and nsIDOMProcessingInstruction nodes.
Drop the nsIDOM everywhere?
::: content/base/src/nsGenericDOMDataNode.h
@@ +8,1 @@
> * nsIDOMCDATASection, and nsIDOMProcessingInstruction nodes.
Same
::: content/base/src/nsINode.cpp
@@ +919,5 @@
> }
> case nsIDOMNode::DOCUMENT_TYPE_NODE:
> {
> + DocumentType* docType1 = static_cast<DocumentType*>(node1);
> + DocumentType* docType2 = static_cast<DocumentType*>(node2);
Consider a DocumentType::FromNode() that asserts the NodeType() is correct
::: content/xml/document/src/nsXMLDocument.cpp
@@ +142,5 @@
> // unlike the legacy HTML mess
> doc->SetDocumentCharacterSet(NS_LITERAL_CSTRING("UTF-8"));
>
> if (aDoctype) {
> + mozilla::ErrorResult res;
Add a "using namespace mozilla;" instead
Attachment #712770 -
Flags: superreview?(bugs)
Attachment #712770 -
Flags: review?(Ms2ger)
Attachment #712770 -
Flags: review+
Comment 6•13 years ago
|
||
Comment on attachment 712770 [details] [diff] [review]
Patch
AFAIK after this change there isn't any sane way to create certain types of
data documents. Is that what we really want at this point?
Could we wait a bit once we have more stuff converted to webidl stuff and
then try to figure out some generic solution.
Attachment #712770 -
Flags: superreview?(bugs) → superreview-
Comment 7•13 years ago
|
||
I'm not aware of such generic solution or plan, but perhaps bz and peterv have some ideas.
Comment 8•13 years ago
|
||
I don't think we have one. We need to either expose some sort of C++ bindings or just make anything we want callable from outside libxul either virtual or exported, right?
Comment 9•8 years ago
|
||
bug 1445140 removed this interface.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
Updated•7 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•