[Webkit-unassigned] [Bug 55481] Consider padding and border when looking for the next/previous line position

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=55481





--- Comment #6 from Mario Sanchez Prada <msanchez at igalia.com>  2011-03-02 02:42:08 PST ---
(In reply to comment #5)
> (From update of attachment 84250 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=84250&action=review
> 
> > Source/WebCore/editing/visible_units.cpp:571
> > -        return renderer->positionForPoint(IntPoint(x - absPos.x(), root->lineTop()));
> > +        return renderer->positionForPoint(IntPoint(x - absPos.x(), root->selectionTop()));
> 
> I can't review this patch as I don't know the difference between lineTop and 
> selectionTop.  I'm hoping that mitz, hyatt, smfr, or darin can review this 
> change.  Also cc enrica & leviw since they are more familiar with the 
> rendering engine than I am.

As far as can extract from the implementation, and having in mind the CSS box model, lineTop() just gives you the Y coordinate (relative to the containing block) of the top boundary for the "net" content of the box, without considering anything else in the CSS box model like padding and border, and that impacts the accuracy of the calculations passed to positionForPoint() when the current box does indeed have non-zero padding or border.

In the other hand selectionTop() does take into account padding and border, so the calculations passed to positionForPoint(), when trying to "hit" another box in the next/previous line, are correct.

What is not so clear to me, is whether this is the right patch to fix the whole issue. Perhaps there are some extra calculations/considerations I should be taking into account here and that could be missing, of course.

Just trying to explain a bit better the rationale behind the current patch

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.