Consider editability when looking for a caret position

Consider editability when looking for a caret position

When determining the Position of a selection point, if the selected one
is not editable we are looking forward and backward for an editable one.

We need to consider whether we are processing an editable content
box/block when computing the position of an inline-box. We also need
to consider editability when looking for a better match based on the
caret's min-offset.

BUG=688015

[jfernandez, 2017-02-07 00:36:25]

Description was changed from

==========
Don't look up forward or backward for an editable caret position

When determining the Position of a seleciton point, if the selected one
is not editable we are looking forward and backward for an editable one.

I'm not sure why we need this, but it's causing weird behavior when
placing the caret on elements with editable and non-editable elements,
specially when targeting inline elements.

BUG=688015
==========

to

==========
Consider editability when looking for a caret position

When determining the Position of a selection point, if the selected one
is not editable we are looking forward and backward for an editable one.

We need to consider whether we are processing an editable content
box/block when computing the position of an inline-box. We also need
to consider editability when looking for a better match based on the
caret's min-offset.

BUG=688015
==========

[jfernandez, 2017-02-07 00:38:47]

jfernandez@igalia.com changed reviewers:
+ yosin@chromium.org

[jfernandez, 2017-02-07 00:47:09]

PTAL

[yosin_UTC9, 2017-02-07 06:06:14]

Could you provide a test case[1] for this change?

It seems mac and win bots failed on:
editing/input/caret-read-only-after-editable.html


[1] Importance and requirements of testing in Chromium
https://goo.gl/OpRI6x

[jfernandez, 2017-02-07 08:32:48]

On 2017/02/07 06:06:14, yosin_BlinkOn_slow wrote:
> Could you provide a test case[1] for this change?
> 

Yeah, sure. There is one available in the bug, which
can be used to reproduce the issue. Defining the proper
regression test will take some time, and since I'm not
totally sure about the general approach of the patch, I'd
like to have some early feedback.

My patch moves the caret to the closest editable area when
focusing a non-editable area. Since there is no official
spec to define the caret behavior, UA implements their own
solutions to each case. Firefox just ignores the focus event
on non-editable elements. 

> It seems mac and win bots failed on:
> editing/input/caret-read-only-after-editable.html
> 

Yes, there are tiny differences in where the caret is finally
placed in some test cases. I'll investigate these issues, but
I'd like to have some feedback on the general approach of
my patch before.

[yosin_UTC9, 2017-02-07 09:16:49]

On 2017/02/07 at 08:32:48, jfernandez wrote:
> On 2017/02/07 06:06:14, yosin_BlinkOn_slow wrote:
> > Could you provide a test case[1] for this change?
> > 
> 
> Yeah, sure. There is one available in the bug, which
> can be used to reproduce the issue. Defining the proper
> regression test will take some time, and since I'm not
> totally sure about the general approach of the patch, I'd
> like to have some early feedback.
> 
> My patch moves the caret to the closest editable area when
> focusing a non-editable area. Since there is no official
> spec to define the caret behavior, UA implements their own
> solutions to each case. Firefox just ignores the focus event
> on non-editable elements. 
> 
> > It seems mac and win bots failed on:
> > editing/input/caret-read-only-after-editable.html
> > 
> 
> Yes, there are tiny differences in where the caret is finally
> placed in some test cases. I'll investigate these issues, but
> I'd like to have some feedback on the general approach of
> my patch before.

I think we don't need to adjust caret position. Caret should be
located at user's specified position.

Current Blink does adjustment to make caret position at visible/editable
position, aka visible position canaonicalization or normalization.

This is source of incompatibility with Firefox/Edge and we are working
for getting rid of this adjustment now.

[jfernandez, 2017-04-04 11:51:13]

I think I need to look for a different approach, so closing this CL for now.