RESOLVED FIXED 141795
Default value of HTMLSelectElement size IDL attribute should be 0.
https://bugs.webkit.org/show_bug.cgi?id=141795
Summary Default value of HTMLSelectElement size IDL attribute should be 0.
Shivakumar J M
Reported 2015-02-19 02:17:14 PST
The Default value of HTMLSelectElement size IDL attribute should be 0. As in spe: http://www.w3.org/html/wg/drafts/html/master/forms.html#the-select-element, "The size IDL attribute has a default value of zero.". in Attached test cases, deafault value is not showing as 0.
Attachments
Patch (6.39 KB, patch)
2015-02-19 22:20 PST, Shivakumar J M
no flags
Patch for landing (6.43 KB, patch)
2015-02-22 20:08 PST, Shivakumar J M
no flags
Shivakumar J M
Comment 1 2015-02-19 22:20:37 PST
Created attachment 246937 [details] Patch Default value of HTMLSelectElement size IDL attribute should be 0.
Andreas Kling
Comment 2 2015-02-20 09:00:22 PST
Comment on attachment 246937 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=246937&action=review r=me > Source/WebCore/ChangeLog:9 > + As in spec: http://www.w3.org/html/wg/drafts/html/master/forms.html#the-select-element, also this matches the behavior of Chrome. Does this also match the behavior of IE and/or Gecko? (AFAICT it does.) It would be good to mention them here as well.
Shivakumar J M
Comment 3 2015-02-22 20:08:50 PST
Created attachment 247095 [details] Patch for landing
Darin Adler
Comment 4 2015-02-23 15:33:55 PST
Comment on attachment 247095 [details] Patch for landing Do <select> elements render properly with a size of 0? What do they look like?
WebKit Commit Bot
Comment 5 2015-02-23 16:17:34 PST
Comment on attachment 247095 [details] Patch for landing Clearing flags on attachment: 247095 Committed r180530: <http://trac.webkit.org/changeset/180530>
WebKit Commit Bot
Comment 6 2015-02-23 16:17:41 PST
All reviewed patches have been landed. Closing bug.
Shivakumar J M
Comment 7 2015-02-24 01:11:18 PST
(In reply to comment #4) > Comment on attachment 247095 [details] > Patch for landing > > Do <select> elements render properly with a size of 0? What do they look > like? After checking with below test, found with size=0 and size=1, the display is fine, the <select> elements render properly. But when the size=3 and size=2, the display is not proper, it always defaults the render size to 4. we need to fix these new issue, when size=3 and size=2. <html> <head> <title>select add test with index</title> </head> <script type="text/javascript"> </script> <select id="test" size=1> <option value="1">aaaaa</option> <option value="2">bbbbb</option> <option value="3">ccccc</option> <option value="4">cccccw</option> </select> </body> </html>
Darin Adler
Comment 8 2015-02-24 09:08:32 PST
(In reply to comment #7) > After checking with below test, found with size=0 and size=1, the display is > fine, the <select> elements render properly. But when the size=3 and size=2, > the display is not proper, it always defaults the render size to 4. > we need to fix these new issue, when size=3 and size=2. That was done intentionally, a long time ago, for the Mac platform, because the scroll bar did not look right at those sizes. It’s possible we can undo this, but we need to be careful about how we handle the scrolling. Historically, everything was based on what looks OK with the Windows user interface. So we can change this, but it will require some non-trivial decisions about how those should look and work on the Mac platform at least.
Shivakumar J M
Comment 9 2015-02-25 03:59:01 PST
(In reply to comment #8) > (In reply to comment #7) > > After checking with below test, found with size=0 and size=1, the display is > > fine, the <select> elements render properly. But when the size=3 and size=2, > > the display is not proper, it always defaults the render size to 4. > > we need to fix these new issue, when size=3 and size=2. > > That was done intentionally, a long time ago, for the Mac platform, because > the scroll bar did not look right at those sizes. It’s possible we can undo > this, but we need to be careful about how we handle the scrolling. > Historically, everything was based on what looks OK with the Windows user > interface. > > So we can change this, but it will require some non-trivial decisions about > how those should look and work on the Mac platform at least. Dear Darin, Yes right, i searched some old bugs, got one issue, which deals with these issue: https://bugs.webkit.org/show_bug.cgi?id=28900, I tried applying these changes and after test for size=2, and 3 the elements are displayed ok, as per size. But the scroll bar did not look right, side bar to scroll to next element was not displayed fine. We can only move to other elements using keyboard up/down arrow keys. I tested in linux with efl minibrowser. Thanks Shiva
Note You need to log in before you can comment on or make changes to this bug.