When there is a block of text followed by a link, the bounds for certain ranges is wrong (specifcally the ranges retreived when asking for next line ranges)
Created attachment 34698 [details] patch I'm no expert about Position(s) but here is what I found comparing two cases. case 1) a block of text case 2) a block of text with a link following the text. Goal: To retrieve the bounds of the second line of text in the block. In the first case, [Position.cpp:983] box = searchAheadForBetterMatch(textRenderer); finds nothing because there's nothing else in the list of siblings. It uses its initial m_offset as the caretPosition.. bounds are then calculated correctly. In the second case, same line position box = searchAheadForBetterMatch(textRenderer); finds the InlineRenderer for the anchor tag. it uses that box's caretMinOffset, which is zero, instead of m_offset. Now the bounds are messed up because we think the caret offset is back to zero My fix, which may be incorrect (but doesn't seem to cause any regression test failures), is that we should only reset the caretOffset to the new box's offset if it's > than the current offset (because we're looking downstream in this case, we shouldn't get a offset less than what we started).
Comment on attachment 34698 [details] patch To me this looks like a workaround for a bug in searchAheadForBetterMatch. Is it possible to fix searchAheadForBetterMatch instead? Are there other calls that would benefit from a fix to that function?
i'll have to look at that method. i'm not sure how many other clients use the bounding boxes of text markers
Comment on attachment 34698 [details] patch will look at searchAheadForBetterMatch
after studying this more, i can't say for sure this is a webkit bug. it may just be a misunderstanding in how the clients are using this API