Bug 53961 – Implement a calendar picker

• Status: RESOLVED
• Resolution: FIXED
• Component: Forms

[Kent Tamura]

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

[Kent Tamura]

Created attachment 81609 [details]
WIP patch

[Kent Tamura]

(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.

[Dimitri Glazkov (Google)]

What do you guys think about implementing createPopup API for this? https://bugs.webkit.org/show_bug.cgi?id=16730

[Simon Fraser (smfr)]

showModalDialog: ugh. Can we make this non-modal?

Are we just doing Gregorian, or other calendars as well?

Is there a spec for this?

[Kent Tamura]

(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.

[Kent Tamura]

(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.

[Dimitri Glazkov (Google)]

(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?

[Kent Tamura]

Created attachment 81937 [details]
WIP patch 2

Proof of concept code for shadow <iframe>

[Kent Tamura]

Created attachment 82769 [details]
WIP patch 3

Calendar picker works.

[Kent Tamura]

(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.

[Kent Tamura]

Created attachment 83281 [details]
WIP patch 4

* Supports keyboard operations.\n* Adjust picker position\n* Fix a TAB focus issue.

[Kent Tamura]

Created attachment 84707 [details]
WIP patch 5

* Apply feedbacks from Chrome UI/UX teams.
* Fix some bugs.

[Darth]

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.

[Kent Tamura]

Created attachment 127315 [details]
WIP Patch 6 (HTMLPopup)

[Kent Tamura]

(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.

[Robert Kroeger]

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.

[Kent Tamura]

(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.

[Kent Tamura]

Created attachment 135271 [details]
WIP Patch 7

[Kent Tamura]

Major parts of the implementation were completed. Closing.