Open Bug 601586 Opened 14 years ago Updated 2 years ago

toString on selection Object is trimming the continuous spaces to one.

Categories

(Core :: DOM: Selection, defect)

Product:
Core
Component:
DOM: Selection
Platform:
x86
Windows 7
Type:
defect

Tracking

()

People

(Reporter: tgvrs_santhosh, Unassigned)

References

(
URL
)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.3 (KHTML, like Gecko) Chrome/6.0.472.63 Safari/534.3
Build Identifier: 4.0b6

I have a contenteditable div whose text is "sample        space       test". Now i will select the textcontent and if i alert selection.toString(), it is trimming spaces to one space. But, if i do selection.getRangeAt(0).toString(), it is persisting the spaces.

Reproducible: Always

Steps to Reproduce:
1. create a contentEditable div whose white-space css style is set to pre;
2. now give text as "sample            space              test".
3. now, select the entire text or part of it such that the spaces will be there.
4. now, check for selection.toString(), it will return string whose white spaces have been trimmed.
5. But, if i check rangeObject.toString(), it is preserving spaces.

Please check the below html code.

<!DOCTYPE HTML PUBLIC '-//W3C//DTD HTML 4.01 Transitional//EN' 'http://www.w3.org/TR/html4/loose.dtd'>
<html>
<head>
    <title>selection toString Test</title>
    <script type="text/javascript">
		function sampleFunc()
		{  
		    var selectionObj = window.getSelection();
		    alert(selectionObj.toString());
		    if (selectionObj.rangeCount > 0)
		    {
		        alert(selectionObj.getRangeAt(0).toString());
		    }
		}
    </script>
</head>
<body>
	<div contenteditable="true" id="sampleDiv" onmouseup="sampleFunc()"><pre>sample      space     test</pre></div>
</body>
</html>
Actual Results:  
continuous spaces have been trimmed out to single space when i do selection.toString().

Expected Results:  
spaces needs to be persisted in the string returned by toString() of selection Object.
Component: General → Selection
Product: Firefox → Core
QA Contact: general → selection
Range toString just grabs raw textnodes from the DOM.

Selection toString uses a text/plain serializer, which does a certain amount of prettyprinting...

That said, losing preformatted spaces seems odd.  The relevant condition in the plaintext serializer is:

1636   if ((mPreFormatted && !mWrapColumn) || IsInPre()
1637       || ((((!mQuotesPreformatted && mSpanLevel > 0) || mDontWrapAnyQuotes))
1638           && mEmptyLines >= 0 && str.First() == PRUnichar('>'))) {

IsInPre() just checks for <pre> elements, and only ones that we actually serialized; perhaps we should fix that?  Or use OutputPreformatted for selections in general?  It's not clear to me what the desired behavior for selection toString is when the text selected is NOT preformatted (note that getRangeAt(0).toString will keep the spaces in that situation too).
(In reply to comment #1)
> That said, losing preformatted spaces seems odd.  The relevant condition in the
> plaintext serializer is:
> 
> 1636   if ((mPreFormatted && !mWrapColumn) || IsInPre()
> 1637       || ((((!mQuotesPreformatted && mSpanLevel > 0) ||
> mDontWrapAnyQuotes))
> 1638           && mEmptyLines >= 0 && str.First() == PRUnichar('>'))) {
> 
> IsInPre() just checks for <pre> elements, and only ones that we actually
> serialized; perhaps we should fix that?

Yes, I think we should.

> Or use OutputPreformatted for
> selections in general?

Hmm, I don't think that we want that for non-preformatted text, do we?

> It's not clear to me what the desired behavior for
> selection toString is when the text selected is NOT preformatted (note that
> getRangeAt(0).toString will keep the spaces in that situation too).

What WebKit does is that it preserves the spaces for preformatted text in selection.toString (and collapses them for non-preformatted text there), and just grabs the raw contents of the text node for range.toString at all times.  I think we should behave the same way.
URL: data:text/html,<div contenteditable="...
OK, I buy that.  Want to do it?  ;)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Sure!
Assignee: nobody → ehsan
Assignee: ehsan → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.