Implement Range-based selection expansion.

Implement Range-based selection expansion.

This patch simplifies Selection.addRange()'s implementation by expanding
the selection based on DOM Ranges instead of VisiblePositions.

There is a slight behavior change caused by this shift of data structures
we use: ranges which are discrete in the DOM tree but visually adjacent will
be rejected after this patch is landed. However, I don't think this will be
a huge problem, since (1) API behavior relying on visual positions can be
tricky to users because they are Blink-internal only information; and
(2) users wishing to connect the regions can (and probably should) specify
a range which overlaps with the current selection.

BUG=346613
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=170640

[yosin_UTC9, 2014-03-20 06:58:26]

I don't think this patch is beneficial for application developers because this
behavior is still incompatible to other browsers.

[Yuta Kitamura, 2014-03-20 07:48:01]

On 2014/03/20 06:58:26, Yoshi wrote:
> I don't think this patch is beneficial for application developers because this
> behavior is still incompatible to other browsers.

Frankly I don't understand your arguments here. Are you
saying we can't update our implementation if it's not
compatible to others? If so we probably should seriously
consider adding multiple-range selection, even if it's
against the specification.

For me it looks unreasonable and unfriendly to users
to leave the implementation  I don't think users
will expect mixed behaviors.

[yosin_UTC9, 2014-03-20 08:20:04]

On 2014/03/20 07:48:01, Yuta Kitamura wrote:
> On 2014/03/20 06:58:26, Yoshi wrote:
> > I don't think this patch is beneficial for application developers because
this
> > behavior is still incompatible to other browsers.
> 
> Frankly I don't understand your arguments here. Are you
> saying we can't update our implementation if it's not
> compatible to others? If so we probably should seriously
> consider adding multiple-range selection, even if it's
> against the specification.
> 
> For me it looks unreasonable and unfriendly to users
> to leave the implementation  I don't think users
> will expect mixed behaviors.

LGTM
OK, I understand you intention. Please go ahead.

[Yuta Kitamura, 2014-03-24 10:28:59]

+Levi, Julie

I would like to hear from you about this change, as a
second opinion...

[leviw_travelin_and_unemployed, 2014-03-26 16:31:14]

The change makes sense, but it'd be good to have it documented somewhere like
MDN so developers can find the expected behavior.

LGTM on the change.

[Yuta Kitamura, 2014-03-27 07:49:24]

After thinking about this, I've come to the conclusion that
I should land this after we pass the M35 branch cut so
this patch would be able to get matured enough in the M36
Canary/Dev channel.

If there's any issue with this plan, let me know.

[leviw_travelin_and_unemployed, 2014-04-01 21:15:38]

On 2014/03/27 07:49:24, Yuta Kitamura wrote:
> After thinking about this, I've come to the conclusion that
> I should land this after we pass the M35 branch cut so
> this patch would be able to get matured enough in the M36
> Canary/Dev channel.
> 
> If there's any issue with this plan, let me know.

I believe we've passed the branch point.

[Yuta Kitamura, 2014-04-02 05:11:10]

The CQ bit was checked by yutak@chromium.org

[commit-bot: I haz the power, 2014-04-02 05:11:22]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/yutak@chromium.org/205903003/20001

[commit-bot: I haz the power, 2014-04-02 07:22:36]

Change committed as 170640