amaralp just moved selection java things into its own directory. I believe aura has all of these things living under ui/ right? so wouldn't be too bad selection for android moves there too.

It's hard to check all the dependency issues that needs to be fixed without actually trying it though. A lot of content dependency is for lifetime issues, and all those needs to be reworked. But there are other things like
content/public/common/context_menu_params.h
content/browser/renderer_host/render_widget_host_view_android.h

and it's not immediately clear how to resolve those.


Disambiguation I don't even know where the code lives right now... wanna point out those files?

The aura code is in ui/touch_selection and ui/views/touchui.

Unfortunately PopupZoomer is still around (discussion with UX/UI team didn't make a good progress), and its Java portion resides in content/browser. Its connection to RWHVA is managed by RenderWidgetHostConnector but now that I see it again there's room for simplification. 

Not sure about the entire SelectionPopupController at this point. Unlike the relatively simple popups above, it makes use of WebContents object inside, which will probably require much more refactoring to make the migration possible.

ui/ is a bit of an odd thing to me.  I recall chatting with sky@ (I believe Bo was there too) where we came to the general thought that ui/ should be for reusable ui components and not for specific ui widgets for a single feature.  I wonder if both of these fall into the latter.  Will select popup be used by more than one place?

That being said, the fact that selection for aura is in UI that is a compelling argument for unifying that (it was moved in 2014 and I think my talk with sky was in 2016, so it also predates that discussion).

hmm... how much logic is there for aura selection handles? I imagine android is a lot more complex.

Alternative is the special type of component that content can depend on. there isn't much of difference in terms of dependencies I think.

> Will select popup be used by more than one place?

No it hasn't been and probably won't be used in more than one place. With the reusability being the criterion, it doesn't seem fit in ui/ - neither is popup zoomer. But then I don't think selection ui is serving multiple purposes either..?

Sounds like the general thought is preferably discouraging any more specific ui components in it going forward.

> hmm... how much logic is there for aura selection handles? I imagine android is a lot more complex.

There is a lot more than just Aura selection handle code in ui/. There is platform independent code in ui/touch_selection/ that is used by both Aura and Android. The TouchSelectionController lives there and that is responsible for converting the selection coordinates we get from the CompositorFrameMetaData into selection events (like SELECTION_HANDLES_SHOWN, SELECTION_HANDLES_MOVED, etc.).

The long-press drag selector also lives in ui/touch_selection. This is what allows you to select more text while you are in a long-press (hold down and wait for the long-press selection to show up, then without lifting your finger drag to select more text). This only works in Android as it's disabled in Aura. 

The other directory ui/views/touchui is where the Aura specific selection menu ui is located and is closer to what Ted was describing (although I'm not really sure how reusable it is).

tl;dr: UI has some pretty complicated selection logic and is more than reusable ui components

Hmm, thinking more, if we were only implementing "simple" selection handles and menus, then there's an argument for putting that in ui/android (the equivalent aura code lives in ui/aura), even if neither is the ideal place.

But all the additional features like inserting more menu items, smart selection, contextual search etc. Those are all additional android features that probably should sit above content, ie a regular component?

amaralp: can you imagine a clean split here?

What do you mean by "simple" selection handles and menus? Would this this include all of SelectionPopupController?

"simple" as in, this makes sense as part of a web platform, or part of any content embedder (which may not be in chromium source at all)

So things like smart selection, contextual search probably don't make the cut.

Renamed the subject as the small popups are now out of the topic.