655512 - Forward implementation of nsIDOMDocument from nsHTMLDocument to nsDocument

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

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

Attachment: Patch v1

The manual forwarding is hurting my attempts to get rid of some nsIDOMDocument* interfaces.

Comment 1

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

http://hg.mozilla.org/mozilla-central/rev/11339a517f79

Comment 2

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Wonderful :-( Thank you so much, you just totally broke BlueGriffon, giving
it its first _major_ loss of functionality.

Why did you forbid CDATASections and PIs in HTML???? There are tons of use
case, the first of them being PHP pseudo-PIs !!!

I am officially requesting a backout of this changeset.

Comment 3

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

There is no black-box-detectable change in this changeset.

Comment 4

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

(In reply to comment #3)
> There is no black-box-detectable change in this changeset.

I don't understand this comment. Care to explain?

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

Daniel, in Fx4, 192, etc 
htmldocument.createCDATASection("foo") throws.
So it does with Nightlies.

What is the change to the behavior?

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

The old code was
CreateCDATASection(const nsAString& aData, nsIDOMCDATASection** aReturn)
{
  if (!IsHTML()) {
    return nsDocument::CreateCDATASection(aData, aReturn);
  }
  // There are no CDATASections in HTML
  *aReturn = nsnull;
   return NS_ERROR_DOM_NOT_SUPPORTED_ERR;
}


The new code is 
CreateCDATASection(const nsAString& aData, nsIDOMCDATASection** aReturn)
{
  NS_ENSURE_ARG_POINTER(aReturn);
  *aReturn = nsnull;

  if (IsHTML()) {
    return NS_ERROR_DOM_NOT_SUPPORTED_ERR;
  }
...

Comment 7

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

D'OH. So this never worked ?!? Then one of my tests of the Toolkits add-on
for BlueGriffon failed w/o notice. I need tests for the tests apparently :-(
If that's the case I _deeply_ apologize.

But the root of the problem still stands:

1. if I understand correctly the code, createCDATASection then throws
   for all nsHTMLDocuments.

2. in that case, it throws also for XHTML1 documents

3. but for validation reasons, it it *extremely* important that editors
   encapsulate the contents of a <script> element inside a CDATA section

4. otherwise, creating a <script> element and its content text node will
   result in the transliteration of all instances of < into &lt; and &
   into &amp;, making the script extremely painful to manipulate

5. I remind you the whole web is full of tutorials strongly recommending
   to encapsulate XHTML <script> contents in CDATA sections with the
   CDATA section start and end tag commented out by a JavaScript comment

I really need a solution here. Making createCDATASection throw for HTML
documents is a total blocker to me.
Similarly, making createProcessingInstruction throw for HTML document is
a total blocker for PHP pseudo-instructions in HTML for my editor.

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #7)
> But the root of the problem still stands:
> 
> 1. if I understand correctly the code, createCDATASection then throws
>    for all nsHTMLDocuments.
> 
> 2. in that case, it throws also for XHTML1 documents
It doesn't throw for XHTML document, only HTML

> I really need a solution here. Making createCDATASection throw for HTML
> documents is a total blocker to me.
It has thrown for HTML documents for ages.

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #8)
> It has thrown for HTML documents for ages.
Apparently since 1998

Comment 10

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

I discussed that with Ms2Ger : the extension of a XHTML file is unpredictable
and is independant of the MIME type. So when a XHTML file is locally saved
under a *.html file, I can't create a CDATASection... Blocker.

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

You can, in a hackish way.
var cdata = document.implementation.createDocument("", "", null).createCDATASection("Foobar");
elementInHTMLDocument.appendChild(cdata);


But anyway, the behavior hasn't changed for ages.