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

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

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

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.

:( 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.

This worksforme. Presumably fixed by sicking's rewrite of most of range to use nsINode. Alex, want to write up a mochitest for this?

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.