Open the attached test case and double click on the word "hello". The following word, "world", which is in a floating div, it also selected, as though it is part of "hello".
Created attachment 78035 [details] test case
<rdar://problem/8824711>
Created attachment 78261 [details] patch
Created attachment 78265 [details] updated patch
Comment on attachment 78265 [details] updated patch Will this cause problems with “drop caps” done as <span style="font-size: x-large; float: left;">O</span>nce upon a time ?
(In reply to comment #5) > (From update of attachment 78265 [details]) > Will this cause problems with “drop caps” done as > <span style="font-size: x-large; float: left;">O</span>nce upon a time > ? Yes the 'O' will be treated as a separate word when selecting by word and for spell checking, but getting that case right would require substantial changes to text iterators: they'll have to keep track of the previous chunk of text, and look ahead to the next chunk to know whether or not to emit for a floating element like that. Those changes warrant a new bug I think.
Comment on attachment 78265 [details] updated patch View in context: https://bugs.webkit.org/attachment.cgi?id=78265&action=review > WebCore/editing/TextIterator.cpp:766 > + if (renderer->isRenderBlock()) > + return ((RenderBlock*)renderer)->height(); I don't quite understand why we need to check the height here. Also, does this work when writing mode is vertical?
Created attachment 78868 [details] patch > I don't quite understand why we need to check the height here. Also, does this work when writing mode is vertical? We don't emit for a floating or positioned element that doesn't take up any space. This is demonstrated in: editing/pasteboard/newlines-around-floating-or-positioned.html I check the element's width(), too. Yes, we will emit if regardless of the writing mode.
Created attachment 78870 [details] patch Updated patch.
(In reply to comment #6) > (In reply to comment #5) > > (From update of attachment 78265 [details] [details]) > > Will this cause problems with “drop caps” done as > > <span style="font-size: x-large; float: left;">O</span>nce upon a time > > ? > > Yes the 'O' will be treated as a separate word when selecting by word and for spell checking, but getting that case right would require substantial changes to text iterators: they'll have to keep track of the previous chunk of text, and look ahead to the next chunk to know whether or not to emit for a floating element like that. Those changes warrant a new bug I think. So this patch will fix one case but regress other known cases. In particular, Find in Page will no longer match the first word of a paragraph with a drop cap. Typically we try to avoid regressions of this sort. Can you exaplain why this is a good tradeoff?
Comment on attachment 78870 [details] patch > So this patch will fix one case but regress other known cases. In particular, Find in Page will no longer match the first word of a paragraph with a drop cap. I hadn't thought about that case. I need to rethink this.
(In reply to comment #10) > (In reply to comment #6) > > (In reply to comment #5) > > > (From update of attachment 78265 [details] [details] [details]) > > > Will this cause problems with “drop caps” done as > > > <span style="font-size: x-large; float: left;">O</span>nce upon a time > So this patch will fix one case but regress other known cases. In particular, Find in Page will no longer match the first word of a paragraph with a drop cap. Typically we try to avoid regressions of this sort. Can you exaplain why this is a good tradeoff? An arguably better trade off proposal: Align with Opera and Firefox. In this example, Firefox and Opera treat "Once" as two words: <div><div style="font-size: x-large; float: left;">O</div>nce upon a time</div> Even in this example, do Firefox and Opera treat "Once" as two words: <div><div display:inline;">O</div>nce upon a time</div> Whereas in this example, Firefox and Opera treat "Once" as a single word: <div><span style="font-size: x-large; float: left;">O</span>nce upon a time</div> So you should not only look at the styling of the elements but also at their semantics. <div> has the semantics of a block element, hence even if it has an inline style, it should be seen as a word splitter. Whereas <span> is an inline element that could also be used inside words.
fwiw, the behavior is identical in Safari and Chrome, both hello and world are selected. Firefox doesn't select the "world" word.
It would help to define what behavior we want before we make any code change. I’m sure Chrome inherited this behavior from WebKit and I’m not sure anyone has thought through what we want. Understanding whether a floating element is expected to be perceived by the user as disjoint or not may be a challenge, so the choice here is likely to be arbitrary rather than obviously meeting user expectations.