Closed Bug 105452 Opened 24 years ago Closed 24 years ago

Annoying assert when outputing DOM to HTML source

Categories

(Core :: DOM: Serializers, defect)

Product:
Core
Component:
DOM: Serializers
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: cmanske, Assigned: peterv)

Details

Steps to reproduce: 1. Create a new Composer page. 2. Click on the HTML Source tab. It always asserts in AppendTextData because the calculated length of the text "frag" to be appended is 0. Note that we don't get this assert when saving to a file. Stack: nsXMLContentSerializer::AppendTextData(nsIDOMNode * 0x0399aa74, int 0, int -1, nsAString & {...}, int 1, int 0) line 109 + 32 bytes nsHTMLContentSerializer::AppendText(nsHTMLContentSerializer * const 0x0422e7f0, nsIDOMText * 0x0399aa74, int 0, int -1, nsAString & {...}) line 161 + 31 bytes nsDocumentEncoder::SerializeNodeStart(nsIDOMNode * 0x0399aa74, int 0, int -1, nsAString & {...}) line 317 nsDocumentEncoder::SerializeToStringRecursive(nsIDOMNode * 0x0399aa74, nsAString & {...}) line 372 + 20 bytes nsDocumentEncoder::SerializeToStringRecursive(nsIDOMNode * 0x0399aaf8, nsAString & {...}) line 393 + 21 bytes nsDocumentEncoder::SerializeToStringRecursive(nsIDOMNode * 0x039886f8, nsAString & {...}) line 393 + 21 bytes nsDocumentEncoder::SerializeToStringRecursive(nsIDOMNode * 0x039887e8, nsAString & {...}) line 393 + 21 bytes nsDocumentEncoder::SerializeToStringRecursive(nsIDOMNode * 0x03989364, nsAString & {...}) line 393 + 21 bytes nsDocumentEncoder::EncodeToString(nsDocumentEncoder * const 0x0422e890, nsAString & {...}) line 927 + 21 bytes nsPlaintextEditor::OutputToString(nsPlaintextEditor * const 0x039fdeb0, nsAString & {...}, const nsAString & {...}, unsigned int 258) line 1560 + 39 bytes nsEditorShell::GetContentsAs(nsEditorShell * const 0x0414a650, const unsigned short * 0x02a40030, unsigned int 258, unsigned short * * 0x0012d4b8) line 3022 + 53 bytes
--> perterv
Assignee: harishd → peterv
Hmm, so does the editor create text nodes without a value (causing the fragment to have length 0)? I can fix it this way if an empty fragment is not an error, but I don't know if it is. Index: mozilla/content/base/src/nsXMLContentSerializer.cpp =================================================================== RCS file: /cvsroot/mozilla/content/base/src/nsXMLContentSerializer.cpp,v retrieving revision 1.14 diff -u -3 -r1.14 nsXMLContentSerializer.cpp --- nsXMLContentSerializer.cpp 2001/10/01 20:37:46 1.14 +++ nsXMLContentSerializer.cpp 2001/11/07 21:43:21 @@ -106,7 +106,7 @@ PRInt32 length = ((aEndOffset == -1) ? frag->GetLength() : aEndOffset) - aStartOffset; if (length <= 0) { - NS_ASSERTION(0, "a start offset is beyond the end of the text fragment!"); + NS_ASSERTION(aStartOffset == 0, "a start offset is beyond the end of the text fragment!"); return NS_OK; // XXX Maybe this should be an error }
I don't know, but Joe or Kin will.
I tried the fix you suggested and it doesn work, so r=cmanske if it looks ok with Joe and/or Kin.
The zero length text node in question here is under the <title> node in the <head> of the document. cmanske is the composer JS adding a zero-length text node to about:blank documents? Or is this <title> and text node coming from the parser? In any case, it is perfectly legal to have zero-length text nodes in the tree, so the assertion change looks fine to me ... I think you should also modify the comment below to something like: - return NS_OK; // XXX Maybe this should be an error + return NS_OK; // XXX Zero is a legal value, maybe non-zero values should be an error. to avoid any future confusion. sr=kin@netscape.com
Of course! Yes, we always add an empty <title> tag to a new document. I agree with kin, please change the comment as suggested.
Checked in with updated comment.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.