Last Comment Bug 655512 - Forward implementation of nsIDOMDocument from nsHTMLDocument to nsDocument
: Forward implementation of nsIDOMDocument from nsHTMLDocument to nsDocument
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: DOM: Core & HTML (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla6
Assigned To: :Ms2ger
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-07 12:24 PDT by :Ms2ger
Modified: 2011-06-13 07:23 PDT (History)
3 users (show)
Ms2ger: in‑testsuite-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Patch v1 (9.58 KB, patch)
2011-05-07 12:24 PDT, :Ms2ger
bugs: review+
Details | Diff | Splinter Review

Description :Ms2ger 2011-05-07 12:24:34 PDT
Created attachment 530869 [details] [diff] [review]
Patch v1

The manual forwarding is hurting my attempts to get rid of some nsIDOMDocument* interfaces.
Comment 2 Daniel Glazman (:glazou) 2011-06-11 02:26:39 PDT
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 2011-06-11 02:31:20 PDT
There is no black-box-detectable change in this changeset.
Comment 4 Daniel Glazman (:glazou) 2011-06-11 02:36:03 PDT
(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] 2011-06-11 03:15:32 PDT
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] 2011-06-11 03:18:56 PDT
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) 2011-06-13 05:54:00 PDT
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] 2011-06-13 05:58:34 PDT
(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] 2011-06-13 05:59:30 PDT
(In reply to comment #8)
> It has thrown for HTML documents for ages.
Apparently since 1998
Comment 10 Daniel Glazman (:glazou) 2011-06-13 07:15:30 PDT
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] 2011-06-13 07:23:05 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.