Closed Bug 157373 Opened 20 years ago Closed 15 years ago

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

Categories

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

x86
All
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: WeirdAl, Unassigned)

References

()

Details

Attachments

(2 files)

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.
reassigning to kin
Assignee: anthonyd → kin
URI is no good anymore; I need to build a new testcase.
Depends on: 58974
Alex, if you get a test case built ... could you try it with the patch I just 
posted in bug 58974?
Attached file test case
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.
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?
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.
Depends on: 304514
:(  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.
Assignee: kinmoz → traversal-range
QA Contact: lchiang → ian
Blocks: acid3
This worksforme.  Presumably fixed by sicking's rewrite of most of range to use nsINode.

Alex, want to write up a mochitest for this?
Status: NEW → RESOLVED
Closed: 15 years ago
Flags: in-testsuite?
Resolution: --- → WORKSFORME
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.
Component: DOM: Traversal-Range → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.