Bug 55886 - RenderBox::localCaretRect should support before/after positions
Summary: RenderBox::localCaretRect should support before/after positions
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 49744
  Show dependency treegraph
 
Reported: 2011-03-07 11:26 PST by Levi Weintraub
Modified: 2011-03-07 11:36 PST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Levi Weintraub 2011-03-07 11:26:18 PST
The current signature of localCaretRect doesn't cover all the types of Positions that can be tied to a container. Namely, receiving only an offset doesn't allow differentiation between the position before a container and the first one inside. Likewise for the last position inside/after. See comment here: http://trac.webkit.org/browser/trunk/Source/WebCore/rendering/RenderBox.cpp#L3016

I propose adding a boolean value such as "caretIsInsideContainer" which is used to determine whether to include border/padding.
Comment 1 Ryosuke Niwa 2011-03-07 11:30:35 PST
(In reply to comment #0)
> The current signature of localCaretRect doesn't cover all the types of Positions that can be tied to a container. Namely, receiving only an offset doesn't allow differentiation between the position before a container and the first one inside. Likewise for the last position inside/after. See comment here: http://trac.webkit.org/browser/trunk/Source/WebCore/rendering/RenderBox.cpp#L3016

Can't we always use the parent anchored equivalent?
Comment 2 Levi Weintraub 2011-03-07 11:36:10 PST
(In reply to comment #1)
> Can't we always use the parent anchored equivalent?

Currently, we actually go out of our way to avoid using the parent anchored equivalent. Notice comment here: http://trac.webkit.org/browser/trunk/Source/WebCore/rendering/RenderBox.cpp#L3015

While possible, doing this would involve pushing much more caret logic down into the renderers, which I believe we want to avoid.