Implement a calendar picker for date, datetime, datetime-local, and week types. My plan is: - Use Windows::showModalDialog() from C++ code - Add a mechanism to load an internal resource via a URL to open it by showModalDialog() - Develop a calendar picker UI by HTML + CSS + JavaScript
Created attachment 81609 [details] WIP patch
(In reply to comment #1) > Created an attachment (id=81609) [details] > WIP patch This patch introduces x-webkit URL scheme. It needs some hacks against the loader and SecurityOrigin. I wonder if this is a right approach. I couldn't use simple file: URLs for a calendar picker file because of SecurityOrigin restrictions. Using showModalDialog() might be not good for user experience and the SecurityOrigin restriction.
What do you guys think about implementing createPopup API for this? https://bugs.webkit.org/show_bug.cgi?id=16730
showModalDialog: ugh. Can we make this non-modal? Are we just doing Gregorian, or other calendars as well? Is there a spec for this?
(In reply to comment #3) > What do you guys think about implementing createPopup API for this? (In reply to comment #4) > showModalDialog: ugh. Can we make this non-modal? Yeah, createPopup() should be much better. I'll try to implement it. A modal dialog stops everything including other tabs and Inspector. Too bad. > Are we just doing Gregorian, or other calendars as well? > Is there a spec for this? The HTML specification doesn't define a picker UI for <input type=date>. We should support other calendars if they have popular demand. Anyway, the input and output of the calendar picker should be date strings in Gregorian calendar. The requirements are: - input: minimum date, maximum date, step value - output: ISO-8601 date in YYYY-MM-DD format, or ISO-8601 week in YYYY-Wnn format - should be localized by the browser locale I investigated a way to use OS-native calendar controls in OS X and Windows, and concluded they were not usable in WebKit.
(In reply to comment #5) > > What do you guys think about implementing createPopup API for this? > > Yeah, createPopup() should be much better. I'll try to implement it. I checked createPopup() behavior, and found it's not so good. http://msdn.microsoft.com/en-us/library/ms533025(v=vs.85).aspx > * The popup object never has focus when it is displayed so processes continue to run in the parent window. > * The popup object does not support text boxes of any kind. > * No elements inside of the popup object can be selected. These are not good. I have confirmed a popup document never fires keyboard events.
(In reply to comment #6) > (In reply to comment #5) > > > What do you guys think about implementing createPopup API for this? > > > > Yeah, createPopup() should be much better. I'll try to implement it. > > I checked createPopup() behavior, and found it's not so good. > > http://msdn.microsoft.com/en-us/library/ms533025(v=vs.85).aspx > > * The popup object never has focus when it is displayed so processes continue to run in the parent window. > > * The popup object does not support text boxes of any kind. > > * No elements inside of the popup object can be selected. > > These are not good. I have confirmed a popup document never fires keyboard events. Yeah, that makes sense. Perhaps we need to define a better abstraction of a similar kind?
Created attachment 81937 [details] WIP patch 2 Proof of concept code for shadow <iframe>
Created attachment 82769 [details] WIP patch 3 Calendar picker works.
(In reply to comment #9) > Created an attachment (id=82769) [details] > WIP patch 3 > > Calendar picker works. I'll suspend the development until shadow DOM refactoring (Bug 48698) is completed. I'd like to add a button to kick the calendar picker to RenderTextControlSingleLine.
Created attachment 83281 [details] WIP patch 4 * Supports keyboard operations.\n* Adjust picker position\n* Fix a TAB focus issue.
Created attachment 84707 [details] WIP patch 5 * Apply feedbacks from Chrome UI/UX teams. * Fix some bugs.
Would be nice to optionally have keyboard shortcuts for calendar date picking. Pressing T chooses today's date, M moves a month ahead keeping day inact etc. So like having accessKey's definable for the calendar buttons.
Created attachment 127315 [details] WIP Patch 6 (HTMLPopup)
(In reply to comment #14) > Created an attachment (id=127315) [details] > WIP Patch 6 (HTMLPopup) I stopped using shadow DOM. The idea is very close to createPopup API which Dimitri wrote in comment #3. * Introduce HTMLPopup class It is created and deleted by WebCore::Chrome. HTMLPopupClient provides an HTML source and can receive resultant values from the popup. * DateInputType implements HTMLPopupClient. Because iOS and Android don't need a calendar picker for type=date, I'll add ENABLE_CALENDAR_PICKER flag.
Comment on attachment 127315 [details] WIP Patch 6 (HTMLPopup) View in context: https://bugs.webkit.org/attachment.cgi?id=127315&action=review > Source/WebKit/chromium/src/WebHTMLPopupImpl.cpp:159 > + m_page->settings()->setScriptEnabled(true); This could be modified to adjust settings for DIP/touch enablement correct? > Source/WebKit/chromium/src/WebHTMLPopupImpl.cpp:279 > + // GESTURE and TOUCH you could make a bug for me for this.
(In reply to comment #16) > (From update of attachment 127315 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=127315&action=review > > > Source/WebKit/chromium/src/WebHTMLPopupImpl.cpp:159 > > + m_page->settings()->setScriptEnabled(true); > > This could be modified to adjust settings for DIP/touch enablement correct? Yes, of course we should support them.
Created attachment 135271 [details] WIP Patch 7
Major parts of the implementation were completed. Closing.