Bug 110964

Summary: Allow text selection region to be computed relative to container
Product: WebKit Reporter: Arvid Nilsson <anilsson>
Component: Layout and RenderingAssignee: Arvid Nilsson <anilsson>
Status: NEW    
Severity: Normal CC: anilsson, eric, esprehn+autocc, jpetsovits, mifenton, ojan.autocc, simon.fraser, tonikitoo, webkit.review.bot
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch darin: review-

Arvid Nilsson
Reported 2013-02-27 03:26:51 PST
Currently, it's possible to compute the absolute quads for text runs, but with a minor tweak it would be possible to compute them relative to container as well. The BlackBerry port has always rendered the selection as a separate overlay to avoid re-rendering the page when selection changes. This is an optimisation. We're now switching to an approach where the selection highlight is drawn using several overlays, one overlay for each container that contains part of the selection. This allows our selection overlay(s) to move along with scrollable divs, frames, fixed pos items, transformed elements etc despite being a separate overlay(s). I want to put the patch up for review here to get your feedback.
Attachments
Patch (4.63 KB, patch)
2013-02-27 07:42 PST, Arvid Nilsson
darin: review-
Arvid Nilsson
Comment 1 2013-02-27 03:31:33 PST
BlackBerry PR #186234
Arvid Nilsson
Comment 2 2013-02-27 07:42:07 PST
Arvid Nilsson
Comment 3 2013-02-27 07:42:48 PST
For your consideration. See also bug #110965 where a similar patch will be posted tomorrow.
Arvid Nilsson
Comment 4 2013-02-28 01:23:06 PST
Comment on attachment 190521 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=190521&action=review > Source/WebCore/rendering/RenderText.cpp:435 > +void RenderText::containerQuadsForRange(Vector<FloatQuad>& quads, RenderBoxModelObject* container, unsigned start, unsigned end, bool useSelectionHeight, bool* wasFixed) I was considering to also allow the caller to pass a MapCoordinatesFlags here, but in my use case the container is always the immediately surrounding container so we don't need to take transforms, fixed etc into account. (Since if there was a transform or fixed pos, that would result in the addition of a new container that will then be the immediately surrounding container). What do you think, should I add a MapCoordinatesFlags for completeness?
Note You need to log in before you can comment on or make changes to this bug.