Proper calculate the handle base
authorAntonio Gomes <a1.gomes@samsung.com>
Fri, 13 Nov 2015 17:47:13 +0000 (13:47 -0400)
committerYoungsoo Choi <kenshin.choi@samsung.com>
Tue, 10 Jul 2018 07:55:23 +0000 (07:55 +0000)
commitbe6e41e95914cab1e2b7e9386d26a2a07851340d
tree24ab2f7cb412603367e94bdde948de0060eeb749
parent54130e32531dd3c6dd77ec7e0617d686ac5e8dd0
Proper calculate the handle base

There two places where we set the "base" position for a handle:
::ShowHandleAndContextMenuIfRequired and ::HandleDragEndNotification.

If one looks close, will realize that they set the base position
using different heuristics:
(1) the former sets it to the CENTER point of the selection bound.
(2) the later sets it to BOTTOM_{LEFT,RIGHT} point of the selection bound.

In a comment on the code, (1) explains why it uses "CENTER":
"dragging one handle would cause movement of the other".
Although this is really the case if we stop using the center
point in favor of bottom_{left,right}, this fixes the problem on
the wrong place. Moreover, (1) actually causes a bug noticeable when
user performs text selection on pages with different font sizes, e.g.:

<head>
<style>
h1 { font-size: 850%; }
p  { font-size: 100%; }
</style>
</head>
<body>
<h1>This is heading</h1>
<p>This is a paragraph.</p>
</body>

When user starts dragging a handle, we calculate the so named "diff_point",
which is an offset from the handle "base" point (set as described above) and
user's actual touch point. On a move, the current handle position is
subtracted by the "diff_point", and result is sent to the renderer as a
selection point.

If user is selecting a text whose font is big, the diff_point will be calculated
as the offset between the center point of the selection bound and the
touch point, which will be large. Then if users drags the handle to select
a content with a smaller font size.
the large "diff_point" value does not apply to the small size content, and
will cause the handle to be disconnected from the selection point.

Patch fixes this by always setting "base position" to the bottom_{left,right}
of the selection bound.
This is also what TouchHandle (used Aura/Android) does; in
ui/touch_selection/touch_handle.cc, see the logic that sets touch_drag_offset_.
Also, patch computes a new offset based on the line height that avoids
synthesizing a point on a line above (or below) the intended line.
See help function .ComputeLineOffsetFromBottom' which mimics its counterpart in
from ui/touch_selection/touch_selection_controller.cc.

Bug: http://107.108.218.239/bugzilla/show_bug.cgi?id=14746

Reviewed by: a.renevier, sns.park

Change-Id: I4352958c279c00a4b7dc9e882d639cde0c91f11e
Signed-off-by: Antonio Gomes <a1.gomes@samsung.com>
tizen_src/chromium_impl/content/browser/selection/selection_controller_efl.cc
tizen_src/chromium_impl/content/browser/selection/selection_handle_efl.cc