Bug 141795

Summary: Default value of HTMLSelectElement size IDL attribute should be 0.
Product: WebKit Reporter: Shivakumar J M <shiva.jm>
Component: DOMAssignee: Shivakumar J M <shiva.jm>
Status: RESOLVED FIXED    
Severity: Normal CC: commit-queue, darin, sam
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch for landing none

Description Shivakumar J M 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.
Comment 1 Shivakumar J M 2015-02-19 22:20:37 PST
Created attachment 246937 [details]
Patch

Default value of HTMLSelectElement size IDL attribute should be 0.
Comment 2 Andreas Kling 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.
Comment 3 Shivakumar J M 2015-02-22 20:08:50 PST
Created attachment 247095 [details]
Patch for landing
Comment 4 Darin Adler 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?
Comment 5 WebKit Commit Bot 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>
Comment 6 WebKit Commit Bot 2015-02-23 16:17:41 PST
All reviewed patches have been landed.  Closing bug.
Comment 7 Shivakumar J M 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>
Comment 8 Darin Adler 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.
Comment 9 Shivakumar J M 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