Bug 83258 - Calendar Picker: Add code to open/close the calendar picker
Summary: Calendar Picker: Add code to open/close the calendar picker
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Kent Tamura
URL:
Keywords:
Depends on:
Blocks: 53961
  Show dependency treegraph
 
Reported: 2012-04-05 01:50 PDT by Kent Tamura
Modified: 2012-04-06 00:46 PDT (History)
3 users (show)

See Also:


Attachments
Patch (17.84 KB, patch)
2012-04-05 02:30 PDT, Kent Tamura
no flags Details | Formatted Diff | Diff
Patch (17.91 KB, patch)
2012-04-05 02:49 PDT, Kent Tamura
no flags Details | Formatted Diff | Diff
Patch 3 (19.30 KB, patch)
2012-04-05 05:38 PDT, Kent Tamura
no flags Details | Formatted Diff | Diff
Patch 4 (17.96 KB, patch)
2012-04-05 05:48 PDT, Kent Tamura
no flags Details | Formatted Diff | Diff
Patch 5 (17.64 KB, patch)
2012-04-05 21:15 PDT, Kent Tamura
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Kent Tamura 2012-04-05 01:50:17 PDT
Calendar Picker: Add code to open/close the calendar picker
Comment 1 Kent Tamura 2012-04-05 02:30:46 PDT
Created attachment 135786 [details]
Patch
Comment 2 Early Warning System Bot 2012-04-05 02:42:01 PDT
Comment on attachment 135786 [details]
Patch

Attachment 135786 [details] did not pass qt-ews (qt):
Output: http://queues.webkit.org/results/12344006
Comment 3 Early Warning System Bot 2012-04-05 02:42:13 PDT
Comment on attachment 135786 [details]
Patch

Attachment 135786 [details] did not pass qt-wk2-ews (qt):
Output: http://queues.webkit.org/results/12355003
Comment 4 Philippe Normand 2012-04-05 02:43:49 PDT
Comment on attachment 135786 [details]
Patch

Attachment 135786 [details] did not pass gtk-ews (gtk):
Output: http://queues.webkit.org/results/12344005
Comment 5 Build Bot 2012-04-05 02:44:34 PDT
Comment on attachment 135786 [details]
Patch

Attachment 135786 [details] did not pass mac-ews (mac):
Output: http://queues.webkit.org/results/12249012
Comment 6 Kent Tamura 2012-04-05 02:49:43 PDT
Created attachment 135789 [details]
Patch

Fix non-Chromium build
Comment 7 WebKit Review Bot 2012-04-05 03:26:58 PDT
Comment on attachment 135789 [details]
Patch

Attachment 135789 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/12341262
Comment 8 Kent Tamura 2012-04-05 05:38:18 PDT
Created attachment 135810 [details]
Patch 3

Fix Chromium-linux build
Comment 9 Kent Tamura 2012-04-05 05:44:28 PDT
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.
Comment 10 Kent Tamura 2012-04-05 05:48:38 PDT
Created attachment 135811 [details]
Patch 4
Comment 11 Kent Tamura 2012-04-05 21:15:35 PDT
Created attachment 135978 [details]
Patch 5

Clean writeDocument() up
Comment 12 Hajime Morrita 2012-04-05 23:48:44 PDT
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.
Comment 13 Kent Tamura 2012-04-05 23:58:33 PDT
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.
Comment 14 Kent Tamura 2012-04-06 00:46:02 PDT
Comment on attachment 135978 [details]
Patch 5

Clearing flags on attachment: 135978

Committed r113416: <http://trac.webkit.org/changeset/113416>
Comment 15 Kent Tamura 2012-04-06 00:46:09 PDT
All reviewed patches have been landed.  Closing bug.