Bug 83258 – Calendar Picker: Add code to open/close the calendar picker

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

[Kent Tamura]

Calendar Picker: Add code to open/close the calendar picker

[Kent Tamura]

Created attachment 135786 [details]
Patch

[Early Warning System Bot]

Comment on attachment 135786 [details]
Patch

Attachment 135786 [details] did not pass qt-ews (qt):
Output: http://queues.webkit.org/results/12344006

[Early Warning System Bot]

Comment on attachment 135786 [details]
Patch

Attachment 135786 [details] did not pass qt-wk2-ews (qt):
Output: http://queues.webkit.org/results/12355003

[Philippe Normand]

Comment on attachment 135786 [details]
Patch

Attachment 135786 [details] did not pass gtk-ews (gtk):
Output: http://queues.webkit.org/results/12344005

[Build Bot]

Comment on attachment 135786 [details]
Patch

Attachment 135786 [details] did not pass mac-ews (mac):
Output: http://queues.webkit.org/results/12249012

[Kent Tamura]

Created attachment 135789 [details]
Patch

Fix non-Chromium build

[WebKit Review Bot]

Comment on attachment 135789 [details]
Patch

Attachment 135789 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/12341262

[Kent Tamura]

Created attachment 135810 [details]
Patch 3

Fix Chromium-linux build

[Kent Tamura]

Morita-san and I discussed how to test ENABLE_CALENDAR_PICKER code.

It gets possible by introducing mock functions for ChromeClient::openPagePopup and closePagePopup. Such mock should be installed by window.internals.

Anyway, we can't add tests until we enable ENABLE_INPUT_TYPE_DATE because we have no code paths to reach the ENABLE_CALENDAR_PICKER code.

[Kent Tamura]

Created attachment 135811 [details]
Patch 4

[Kent Tamura]

Created attachment 135978 [details]
Patch 5

Clean writeDocument() up

[Hajime Morrita]

Comment on attachment 135811 [details]
Patch 4

View in context: https://bugs.webkit.org/attachment.cgi?id=135811&action=review

Although this isn't related this change, I hope ChromeClient has no more #ifdefs and have a supplemental  instead.

> Source/WebCore/html/shadow/CalendarPickerElement.cpp:163
> +void CalendarPickerElement::writeDocument(DocumentWriter& writer)

My personal feeling is that this kind of HTML generation won't be part of WebCore. I understand there are controversy though.

[Kent Tamura]

Comment on attachment 135811 [details]
Patch 4

View in context: https://bugs.webkit.org/attachment.cgi?id=135811&action=review

You added a comment to an obsolete attachment.

>> Source/WebCore/html/shadow/CalendarPickerElement.cpp:163
>> +void CalendarPickerElement::writeDocument(DocumentWriter& writer)
> 
> My personal feeling is that this kind of HTML generation won't be part of WebCore. I understand there are controversy though.

Do you have alterative ideas?
This will be used by multiple platforms, and we wan't have much code in Chromium WebKit layer.  I don't think we have a choice other than WebCore.

[Kent Tamura]

Comment on attachment 135978 [details]
Patch 5

Clearing flags on attachment: 135978

Committed r113416: <http://trac.webkit.org/changeset/113416>

[Kent Tamura]

All reviewed patches have been landed.  Closing bug.