Need help with newline handling

[Germain Garand]

Le dimanche 28 février 2010, Harri Porten a écrit :
> Hello,
>

Hi Harri!

> I need some advise on how to handle
> https://bugs.kde.org/show_bug.cgi?id=58111 which is about copy&paste
> problems. What happens is that a user who copies HTML like this
>
> ==============
> <p>coucou<br>
> hop<br>
> ==============
>
> gets the text "coucou<newline><space>hop". The leading space is
> superfluous. I've tracked it down to the following: setText() is called on
> the RenderText object for the "hop" string. It has a leading newline
> character which gets turned into a space by
> DOMString::collapseWhiteSpace()[1]. Since our copy&paste code makes us of
> the text stored in the Render objects it'll put this space into the
> clipboard as well.
>
> I wonder if it's the right thing to convert leading newlines that way.
> Trying a patch that collapses leading newlines completely (attached) but
> got a lot of visible regressions from our test suite.

I don't think this is possible because whitespace can only be ignored at the 
beginning of blocks. The render text might be part of an inline flow, in which 
case the newline would be significant:

<div>X<span>
Y</span>

>
> My question: is the collapsing code in RenderText::setText() the right
> place to fix the issue? Or should I restrict the fix to the
> KHTMLPart::selectedText() function?

yes I'd say KHTMLPart::selectedText() is the best place.
The ultimate knowledge about visually significant whitespace is detained by 
the inline boxes, so somehow an iteration over the RenderText's 
InlineTextBoxes should be used instead of the raw renderedString (which is a 
bit of a misnomer).

maybe some RenderText method could return the correct visual string based on 
the RenderPosition offsets?

Germain