102404 2012-11-15 09:42:20 -0800 Implementing PAGE_POPUP for android 2013-04-08 11:11:39 -0700 1 1 1 Unclassified WebKit Platform 528+ (Nightly build) Unspecified Unspecified RESOLVED WONTFIX P2 Normal --- 1 miguelg miguelg abarth keishi peter tkent yosin oldest_to_newest 768190 0 miguelg 2012-11-15 09:42:20 -0800 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. 768290 1 abarth 2012-11-15 10:45:55 -0800 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. 768896 2 tkent 2012-11-15 21:05:34 -0800 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)". 769075 3 miguelg 2012-11-16 03:34:41 -0800 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. 769093 4 peter 2012-11-16 03:53:56 -0800 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. 770447 5 tkent 2012-11-19 01:02:46 -0800 (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. 770533 6 miguelg 2012-11-19 03:01:08 -0800 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. 870944 7 peter 2013-04-08 11:11:39 -0700 Resolving as WontFix given that Chromium moved to Blink.