[Experimental, WIP] Demo version of extracting WebView selection data from CompositorFrame.

Demo version of extracting WebView selection data from CompositorFrame.

This CL shows a proposed outline of how we might extract frame selection
information from CompositorFrame metadata, and ensure that only the
focused element's selection data is output.

Imagine that, in place of fprintf() statements, we forward the selection
data to a central controller for touch-selection handles (one per view
hierarchy).

BUG=

[wjmaclean, 2015-06-24 19:28:34]

Here's a rough outline of how we *might* wire it up ... please comment.

BTW, I've been trying it out using a sample test app from
https://code.google.com/p/chromium/issues/detail?id=499766 (see file
webview.zip).

The app has three webviews embedded in a page; you can make text selections in
any of them, and you can scroll the middle webview a bit to see the updates. You
can place a blinking cursor in the embedder's input boxes, or highlight multiple
characters in one of those boxes.

[mohsen, 2015-06-30 22:32:22]

Thanks for putting this together, James, and sorry for my late response. This
looks good to me. I'll try it with my unification patch, ASAP.

[mfomitchev, 2015-07-02 15:50:44]

Thanks for putting this together James!
I think adding extra state (focused_node_is_plugin) to RWHVB to support this is
a bit unfortunate.
I wonder if we can instead make the selection controller understand which RWHV
the selection info is coming from (e.g. by sending along some sort of a an id)
and then send the selection info to the controller from all RWHVs whenever their
selection state changes - regardless of the focus state. This should allow the
selection controller keep track of which RWHV has the "active" selection and
resolve the potential races. If we succeed with this, there would be no need for
focused_node_is_plugin state in RWHVB, all the added complexity would be
contained in the selection controller, which I think would be better.

[wjmaclean, 2015-07-02 16:06:36]

On 2015/07/02 15:50:44, mfomitchev wrote:
> Thanks for putting this together James!
> I think adding extra state (focused_node_is_plugin) to RWHVB to support this
is
> a bit unfortunate.
> I wonder if we can instead make the selection controller understand which RWHV
> the selection info is coming from (e.g. by sending along some sort of a an id)
> and then send the selection info to the controller from all RWHVs whenever
their
> selection state changes - regardless of the focus state. This should allow the
> selection controller keep track of which RWHV has the "active" selection and
> resolve the potential races. If we succeed with this, there would be no need
for
> focused_node_is_plugin state in RWHVB, all the added complexity would be
> contained in the selection controller, which I think would be better.

I suppose this could be done, though at present it is possible for both the
guest and embedder to each think that they have an active selection, which is
why I thought we would need focus information in the first place. I had thought
that the "is plugin" concept wasn't too disimilar to "is editable", but is *is*
extra state for RWHVB to carry..

But I'm not opposed to letting the selection controller figure it all out; I
just don't know what the best criteria is to determine which selection is
currently "active" from the point of view of the selection handles.

[mfomitchev, 2015-07-06 16:40:10]

On 2015/07/02 16:06:36, wjmaclean wrote:
> On 2015/07/02 15:50:44, mfomitchev wrote:
> > Thanks for putting this together James!
> > I think adding extra state (focused_node_is_plugin) to RWHVB to support this
> is
> > a bit unfortunate.
> > I wonder if we can instead make the selection controller understand which
RWHV
> > the selection info is coming from (e.g. by sending along some sort of a an
id)
> > and then send the selection info to the controller from all RWHVs whenever
> their
> > selection state changes - regardless of the focus state. This should allow
the
> > selection controller keep track of which RWHV has the "active" selection and
> > resolve the potential races. If we succeed with this, there would be no need
> for
> > focused_node_is_plugin state in RWHVB, all the added complexity would be
> > contained in the selection controller, which I think would be better.
> 
> I suppose this could be done, though at present it is possible for both the
> guest and embedder to each think that they have an active selection, which is
> why I thought we would need focus information in the first place. I had
thought
> that the "is plugin" concept wasn't too disimilar to "is editable", but is
*is*
> extra state for RWHVB to carry..
> 
> But I'm not opposed to letting the selection controller figure it all out; I
> just don't know what the best criteria is to determine which selection is
> currently "active" from the point of view of the selection handles.

(Sorry, somehow I was removed from the reviewers/CC list, so I missed this
reply)

I think the controller should be able to deal with multiple "active" selections.
It can get focus status through RWHV::Focus(), it gets called on touch events,
on Aura it listens to global events through Env. Based on all of these, I think
it should be able to determine which selection (if any) needs the handles to be
drawn. The problem right now is that the controller has no way of
differentiating between the selection info from the embedder vs. the selection
info from guest. So one can overwrite the other. If we send IDs along with the
selection info - that would be solved.

[wjmaclean, 2015-07-06 16:58:26]

> 
> (Sorry, somehow I was removed from the reviewers/CC list, so I missed this
> reply)

Not sure how that happened, sorry! I've added you back.
 
> I think the controller should be able to deal with multiple "active"
selections.
> It can get focus status through RWHV::Focus(), 

Keep in mind that the RWHV for the embedder will have focus at the same time the
RWHV for the guest has focus, since the BrowserPlugin in the embedder must have
focus in order for the Guest to have focus(). There's a whole chain of focused
elements, though it can be 'traversed' (inferred?) if we know the embedder-guest
pairs.

> it gets called on touch events,
> on Aura it listens to global events through Env. Based on all of these, I
think
> it should be able to determine which selection (if any) needs the handles to
be
> drawn. The problem right now is that the controller has no way of
> differentiating between the selection info from the embedder vs. the selection
> info from guest. So one can overwrite the other. If we send IDs along with the
> selection info - that would be solved.

Couldn't the (new?) controller keep track of *all* the selection ranges, and
then decide which one to attach the handles to? Certainly we can send additional
info along to the controller ... which "ID"s did you have in mind?

[mfomitchev, 2015-07-06 17:39:35]

On 2015/07/06 16:58:26, wjmaclean wrote:
> > 
> > (Sorry, somehow I was removed from the reviewers/CC list, so I missed this
> > reply)
> 
> Not sure how that happened, sorry! I've added you back.
>  
> > I think the controller should be able to deal with multiple "active"
> selections.
> > It can get focus status through RWHV::Focus(), 
> 
> Keep in mind that the RWHV for the embedder will have focus at the same time
the
> RWHV for the guest has focus, since the BrowserPlugin in the embedder must
have
> focus in order for the Guest to have focus(). There's a whole chain of focused
> elements, though it can be 'traversed' (inferred?) if we know the
embedder-guest
> pairs.

Hmm.. yeah, that complicates things, especially for deeply nested structures,
which I guess are possible.
If all else fails, I think we could use the changes you made in
FocusedNodeChanged to let the controller know the leaf focused RWHV.
But we may not even need that - the existing hooks like OnTouchEvent and Env
listener may be enough.


> > it gets called on touch events,
> > on Aura it listens to global events through Env. Based on all of these, I
> think
> > it should be able to determine which selection (if any) needs the handles to
> be
> > drawn. The problem right now is that the controller has no way of
> > differentiating between the selection info from the embedder vs. the
selection
> > info from guest. So one can overwrite the other. If we send IDs along with
the
> > selection info - that would be solved.
> 
> Couldn't the (new?) controller keep track of *all* the selection ranges, and
> then decide which one to attach the handles to? Certainly we can send
additional
> info along to the controller ... which "ID"s did you have in mind?

Yep, that's what I was thinking as well. The ID would just identify RWHV which
is the origin of the frame/selection info in some way.

[mfomitchev, 2015-07-13 14:38:55]

mfomitchev@chromium.org changed reviewers:
+ mfomitchev@chromium.org, mohsen@chromium.org