IETC HTM5: verify HTMLDatalistElement fails. http://samples.msdn.microsoft.com/ietestcenter/html5/show_forms_test.htm?datalistelement1 Add HTMLDatalistElement to DOMWindow.idl for consistency. HTMLDatalistElement Constructor should be available on DOMWindow.
Created attachment 131999 [details] patch patch
Comment on attachment 131999 [details] patch Attachment 131999 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/11957499 New failing tests: fast/forms/datalist_prototype_constructor.html
Created attachment 132004 [details] Updated Patch HTML5 datalist element is not enabled in chromium as its implementation is incomplete. Hence skipping the test case in chromium.
Comment on attachment 132004 [details] Updated Patch View in context: https://bugs.webkit.org/attachment.cgi?id=132004&action=review > LayoutTests/ChangeLog:13 > + * fast/forms/datalist_prototype_constructor-expected.txt: Added. > + * fast/forms/datalist_prototype_constructor.html: Added. We usually use '-' to concatenate words, not '_'. The test looks a copy of IETC code. Is the license of the IETC test compatible with WebKit? You need to update other tests such as LayoutTests/fast/dom/window/window-properties.html.
Comment on attachment 132004 [details] Updated Patch View in context: https://bugs.webkit.org/attachment.cgi?id=132004&action=review > Source/WebCore/ChangeLog:3 > + IETC HTM5: verify HTMLDatalistElement. instanceof HTMLDataListElement fails. HTM5 -> HTML5 HTMLData*l*istElement -> HTMLDataListElement
> The test looks a copy of IETC code. Is the license of the IETC test compatible with WebKit? I believe so: http://samples.msdn.microsoft.com/ietestcenter/support/copyright.htm
Created attachment 132576 [details] Updated Patch with review comments. > HTM5 -> HTML5 > HTMLData*l*istElement -> HTMLDataListElement Done. > You need to update other tests such as LayoutTests/fast/dom/window/window-properties.html. I added 'HTMLDataListElement' to LayoutTests/fast/dom/Window/resources/window-properties.js. Following tests needs to be rebaselined: 1. fast/dom/Window/window-properties.html 2. fast/dom/Window/window-property-descriptors.html. I have rebaselined it for GTK platform, for rest of the platforms I have added them to test_Expectations.txt/Skipped. Since the above mentioned tests cover this change, I have removed the Layout test that I had copied earlier from IETC test suite.
Created attachment 132578 [details] Updated Patch
Comment on attachment 132578 [details] Updated Patch View in context: https://bugs.webkit.org/attachment.cgi?id=132578&action=review > LayoutTests/platform/mac/test_expectations.txt:417 > + > +// Need rebaselining. https://bugs.webkit.org/show_bug.cgi?id=81196 > +BUGWK81196 : fast/dom/Window/window-properties.html = TEXT > +BUGWK81196 : fast/dom/Window/window-property-descriptors.html = TEXT You know how the results will change. I recommend updating *-expected.txt manually rather than skipping the tests.
Comment on attachment 132578 [details] Updated Patch r- because of my comment. Also, ENABLE_DATALIST was disabled for many ports, and we need no changes of Skipped/test_expectations.txt for such ports.
Comment on attachment 132578 [details] Updated Patch View in context: https://bugs.webkit.org/attachment.cgi?id=132578&action=review > Source/WebCore/page/DOMWindow.idl:412 > + attribute HTMLDataListElementConstructor HTMLDataListElement; Don't we have a [Conditional=DATALIST] idl option that does this these days?
Comment on attachment 132578 [details] Updated Patch cq- given r-.
This issue is more important than just for consistency. Due to the fact, that Safari still reports true on ('list' in document.createElement('input')) and gives a false positive for feature detection. Testing for the global HTMLDataListElement has become the famoust feature detection to distinguish between input[list]/datalist supporting browsers and none supporting browsers. This is also part of Modernizr. So it is cruical to implement this property as soon as a basic datalist including UI is implemented. @tkent Currently Chrome "20.0.1113.0 canary" returns a false negative for datalist. Should I fill an issue in the Chrome bugtracker?
(In reply to comment #13) > Currently Chrome "20.0.1113.0 canary" returns a false negative for datalist. Should I fill an issue in the Chrome bugtracker? No, you don't need to file another issue.
If Deepak won't update the patch in a few days, someone in my team will take this over.
Hi Kent, I am tied up with other things, wont be able to pick this up. Feel free to assign this to your team.
Created attachment 139144 [details] Patch
Comment on attachment 139144 [details] Patch ok
Comment on attachment 139144 [details] Patch Clearing flags on attachment: 139144 Committed r115446: <http://trac.webkit.org/changeset/115446>
All reviewed patches have been landed. Closing bug.