157373 - Range.selectNodeContents(document).toString() returns ""

Status: RESOLVED WORKSFORME

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

Description

[Alex Vincent [:WeirdAl]]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0) Gecko/20020530
BuildID:    Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0) Gecko/20020530
            Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a+) Gecko/20020714

The DOM-2 Range specification states the selectNodeContents() method of Range
objects may receive any type of node.  However, in the course of my
experimentation, I found our Mozilla implementation does not capture the
contents of a Document node properly.

Reproducible: Always
Steps to Reproduce:
1.  Visit the URI above.
2.  Compare the textarea in the top (which checks document), against the
textarea in the bottom (which checks document.documentElement)


Actual Results:  The bottom textarea has content, the text input corresponding
has a number indicating how many characters there are.

The top textarea has no content, and the text input corresponding has a value of
"0".

Expected Results:  The bottom and top textareas have matching content, the text
inputs corresponding with a matching number indicating how many characters there
are.

Hendikins has verified this bug in a recent CVS build on Linux; mine is 1.0 on
Win98SE.

Comment 1

[rubydoo123]

reassigning to kin

Comment 2

[Alex Vincent [:WeirdAl]]

URI is no good anymore; I need to build a new testcase.

Comment 3

[kinmoz]

Alex, if you get a test case built ... could you try it with the patch I just 
posted in bug 58974?

Comment 4

[Yuh-Ruey Chen]

Attachment: test case

Comment 5

[Alex Vincent [:WeirdAl]]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050811
SeaMonkey/1.0a

I realized that the current testcase isn't specific enough.  The URL above shows
that selectNodeContents works, but the toString() fails.

Comment 6

[Alex Vincent [:WeirdAl]]

http://lxr.mozilla.org/seamonkey/source/content/base/src/nsRange.cpp#2052

cStart and cEnd are both null pointers.  I'm beginning to suspect that
nsDocument and its friends (nsHTMLDocument, etc.) do not implement nsIContent,
and that's why the QI returns null pointers.

Thoughts?

Comment 7

[Alex Vincent [:WeirdAl]]

Attachment: patch, v1 (Not ready for check-in)

With this patch, running the testcase, we get an assertion-loop-to-hang:

###!!! ASSERTION: Null current node in an iterator that's not done!:
'mCurNode', file c:/mozsource/mozilla/content/base/src/nsContentIterator.cpp,
line 1191

I believe it's because of nsContentIterator::Init(nsIDOMRange* aRange), at
mCommonParent = do_QueryInterface(dN);

http://lxr.mozilla.org/seamonkey/source/content/base/src/nsContentIterator.cpp#399


Here again is a case where we QI a DOM node for nsIContent, and get null
instead...  This patch fixes it for nsRange::ToString(), I think.

Comment 8

[Alex Vincent [:WeirdAl]]

:(  I hit another instance where nsIContent and nsIDOMNode didn't necessarily
coexist:  attributes.  

On about:blank, 
javascript:var x =
document.createRange();x.setStart(document.documentElement.attributes[0], 0);
x.setEnd(document.documentElement.attributes[0], 1);alert(x.toString())

Expected results in alert: http://www.w3.org/1999/xhtml
Actual results:

Similarly, document fragments and entity references will exhibit this bug as well.

Comment 9

[Boris Zbarsky [:bzbarsky]]

This worksforme.  Presumably fixed by sicking's rewrite of most of range to use nsINode.

Alex, want to write up a mochitest for this?

Comment 10

[Alex Vincent [:WeirdAl]]

Normally, I would say "Sure, no problem" - and do it a month later.  :)

But right now, I'm awfully darn swamped at work, and haven't touched trunk source for at least two months.  It's best if you ask someone else, to be honest.

When did sicking do that rewrite?  I read my bugmail, but I don't recall seeing that one.