Bug 102404 – Implementing PAGE_POPUP for android

• Status: RESOLVED
• Resolution: WONTFIX
• Component: Platform

[Miguel Garcia]

We are trying to figure out how to implement PAGE_POPUP for the android platform. I have done a cursory inspection on the code and it seems we need to implement the following method

http://code.google.com/searchframe#OAMlx_jo-ck/src/content/browser/renderer_host/render_widget_host_view_android.cc&type=cs&l=80

RenderWidgetHostViewAndroid::InitAsPopup will need to expose a surface where content can be drawn and rendered. That seems to be all really.

I've been looking at the gtk implementation in

http://code.google.com/searchframe#OAMlx_jo-ck/src/content/browser/renderer_host/render_widget_host_view_gtk.cc&exact_package=chromium&q=InitAsPopup%20file:cc&type=cs&l=599

And found that a whole new window is created. If at all possible I'd like to understand the reasoning since for Android this would be fairly expensive (we will need a new renderer process probably). Another alternative for example would be to inject an iframe for example and just render it there.

If creating a new window is the only way to go we might consider using the android WebView to render that html. The very first use case for us is implementing INPUT_TYPE_COLOR and the rendered color picker is not very complicated so any feedback on a simple solution for this would be very welcome.

[Adam Barth]

I don't think you'll be able to get away with using the android WebView.  We're likely to add code to page popup that needs to work with a precise version of WebKit.

[Kent Tamura]

I don't think PAGE_POPUP should be implemented for Android.

Desktop Chromium uses PAGE_POPUP for datalist support of input[type=color]. Android port doesn't support datalist yet, we can add datalist-related members to WebColorChooserClient, and we can implement it with native code for Android.

ColorChooserUIController.cpp should have some "#if ENABLE(PAGE_POPUP)".

[Miguel Garcia]

Thanks for all your comments!


I like the idea of removing the dependency that INPUT_TYPE_COLOR has on PAGE_POPUP. I already removed other unecesary deps in that area (see https://bugs.webkit.org/show_bug.cgi?id=102379) and while this one is slightly less straight forward it should be doable as well.


So let's assume I do that, eventually we would like to implement datalist as well right? Once we get there we will end up having the same problem if I understand correctly so I guess the question still applies.

If using WebView is deemed problematic we can probably hook thinks up so we use the same rendering pipeline we use on a regular tab. However I still wonder why do we need to span a whole new window here and if there would be some other alternatives to implement this.

[Peter Beverloo]

Thank you for the replies! Using an Android WebView would be problematic here for various reasons, indeed.

What are the constraints causing us to be unable to re-use the HTML-based popups used by form validation? For the limited amount of options of a color picker it may make sense to do it in-page, although I'm inclined to agree that for other input types with a datalist it's a much more <select>-like approach, which indeed is native in Android. Nit here is that suggestions aren't supported there, so we'd need a custom control.

Miguel is currently looking in to implementing a color picker without data-list support, as he wrote.

[Kent Tamura]

(In reply to comment #3)
> So let's assume I do that, eventually we would like to implement datalist as well right? Once we get there we will end up having the same problem if I understand correctly so I guess the question still applies.

Right, we'd like to support datalist on Android too.
I think we don't need to use PAGE_POPUP for type=color datalist UI on Android. The desktop UI implementation of type=color datalist is not so complex and I hope implementation with Android-native code is not hard.

(In reply to comment #4)
> What are the constraints causing us to be unable to re-use the HTML-based popups used by form validation? For the limited amount of options of a color picker it may make sense to do it in-page, although I'm inclined to agree that for other input types with a datalist it's a much more <select>-like approach, which indeed is native in Android. Nit here is that suggestions aren't supported there, so we'd need a custom control.

The form validation message UI was build with Shadow DOM, and PAGE_POPUP is not Shadow DOM. Shadow DOM is not suitable for popup-like UI because of focus handling, document boundary, etc.

BTW, we're going to stop using Shadow DOM for the form validation message UI.  Bug 95527.

[Miguel Garcia]

It's a pity that we cannot try a cross platform way of building this, I guess I'll start looking into doing it natively.

[Peter Beverloo]

Resolving as WontFix given that Chromium moved to Blink.