Bug 123314 – <select size> broken on safari, chrome, silk smartphone webkit browsers

• Component: Forms
• Status: RESOLVED INVALID

[Dan Goldman]

1. Version

I do not know the webkit version, so I initially assigned to the most recent version. But I know 100% the bug happens under the following browsers:

safari browser on ipod 4G
silk browser in kindle fire hd
chrome browser on galaxy player 4.2

There is a chance that the bug has been fixed in the most recent version of webkit. This can only be confirmed by the developers, I have no way of telling if the bug exists in the most recent version of webkit. If the bug has already been fixed, that would be great.

The bug does NOT occur in any webkit desktop browser, based on my testing with safari and chrome.

2. Component

I am filing this under "New Bugs". It would seem to fall under "Forms" or possibly "Layout and Rendering". The problem is specifically that <select size> does not work correctly under the smartphone and other non-desktop webkit implementations, that SIZE is ignored.

3. Platform / OS

This bug occurs on at least the following platforms and operating systems, so I could not make a single selection:

safari browser on ipod 4G
silk browser in kindle fire hd
chrome browser on galaxy player 4.2

The bug does NOT occur in any webkit desktop browser, based on my testing with safari and chrome.

4. Priority

I would suggest P2 priority, for the following reasons:

The bug is 100% reproducible
The bug causes any site using <size select> to not function in a non-trivial way. The bug causes the site using <size select> to lose so much functionality to be essentially not usable.

Because this is a bug means that webkit is NOT compliant with a basic HTML functionality, it could easily be considered as P1 priority.

5. Severity

For any web site that relies on <select size> the severity would be the highest Blocker level, because the bug destroys the functionality of the page, makes it unusable. The priority is certainly not less than Normal. I would think this would an urgent bug to fix, because it means that webkit is NOT compliant with a basic HTML functionality, so I assigned Critical.

6. URL

http://www.w3.org/MarkUp/Test/HTML401/current/tests/17_6-BF-01.html is the key URL to demonstrate the bug. This is a w3c page to "Verify the functionality of the size attribute of the SELECT element." The test is "Three options shall be visible at the same time since "size = 3" is set on the SELECT element.". The smartphone webkit browsers fail the test, so webkit is not compliant with a basic HTML functionality.

7. Summary

<select size> broken on safari, chrome, silk smartphone webkit browsers

8. Description

First, do I also need to post this bug to the chromium (or blink) group? Please let me know.

------------------ Basic description
 
There is a problem how webkit-based smartphone browsers display the HTML "select" tag when the "size" attribute is used. No matter what "size" is set to, the smartphone browser displays it as one line, and totally empty if no option selected. The problem was noticed on kindle fire (amazon silk), ipod (safari) and galaxy player (chrome), all of which are webkit-based smartphone-type browsers.

Here are screenshots of a w3schools example that shows the problem (vs correct display):

http://www.ehdp.com/out/silk-select-size-fails.png - silk fails badly.
http://www.ehdp.com/out/desktop-select-size-works.jpg - Any desktop browser passes.

Here are the w3schools pages with the <select size="3"> example:

http://www.w3schools.com/tags/att_select_size.asp
http://www.w3schools.com/tags/tryit.asp?fi...tml_select_size

There is nothing special about w3schools here, or the number "3". It is just a convenient example to test <select size> HTML tag.

It is of course needed to modify browser behavior in some cases to make the user experience better on smartphone. But this is not one of those cases. This is not just a cosmetic difference. This severely damages or makes basically unusable any website designed to use the "size" attribute. For example, try the following (the ones of concern to bug reporter) on desktop vs smartphone:

http://www.ehdp.com/vn/ro/txu1/pd1/dgw/en_US/index.htm - SELECT boxes messed up
http://www.ehdp.com/vn/ro/txu1/pd1/dgw/en_US/ajax.htm - change age or "race of woman"

Below are two desktop screenshots showing correct appearance and function of "select size" situations. The pages are totally destroyed, both appearance and function, when the webkit smartphone browser ignores the "size" attribute.

http://www.ehdp.com/vw-ajx/img02-bb1.htm
http://www.ehdp.com/vw-ajx/img03-bb1.htm

If the developer wants the select box to be three lines tall, why should the smartphone or other device overrule that choice? Why not let the developer, decide? There is no advantage of wiping out "size", there is no user benefit. If it was just a cosmetic difference, it would not matter. But it is a huge functional difference. It makes the select box display and work incorrectly, severely messes up the interface.

------- This DOES break a basic HTML functionality, really is a bug.

 http://www.w3.org/TR/html401/interact/forms.html#adef-size-SELECT 4.01 says:

"If a SELECT element is presented as a scrolled list box, this attribute specifies the number of rows in the list that should be visible at the same time. Visual user agents are not required to present a SELECT element as a list box; they may use any other mechanism, such as a drop-down menu." 

The HTML 4 "not required" text seems to permit SIZE to be ignored. Based on that some might argue that there is no bug, that <select size> is not broken on webkit browsers. However, this is not a sustainable argument, for three reasons:

1) "not required" almost certainly pertains to devices that do not allow a scrolled list box. So there seems no excuse for webkit not to honor the SIZE attribute. The text does not encourage SIZE being ignored, just allows it under certain cases. This is NOT one of those cases.

2) http://www.w3.org/MarkUp/Test/HTML401/current/tests/17_6-BF-01.html HTML 4 test case clearly says "Three options shall be visible at the same time since "size = 3" is set on the SELECT element". This clearly shows the intent that SIZE be honored by HTML 4. The webkit smartphone browser implementations fails the test, and thus are not compliant with HTML 4.

3) http://www.w3.org/TR/html5/forms.html#the-select-element HTML 5 standard just says "The size attribute gives the number of options to show to the user." and dispenses with the "not required" text. Therefore, the webkit smartphone browsers are not compliant with HTML 5.

------ If a "design decision", it is wrong decision, still breaks HTML, needs to be corrected

Was this a "design decision"? If not, then this is 100% a bug, and this section need to read no further.

1) If a "design decision", it might be argued that the purpose was to prevent a select element from using too much space. But this argument holds no water:

Just because something "could" happen, and something relatively minor (too much space), it doesn't logically follow to totally ignore SIZE attribute in smartphone, especially because the downside (wreck the interface usability) is so destructive. A developer uses <select size> for a special purpose, they have a reason, but the webkit smartphone browsers ignore the developer's need, destroy the functionality. The designers of HTML included <select size> for good reasons, but the webkit browser arbitrarily removes that functionality. Finally, any developer is aware that a smartphone has a smaller interface. If they choose, the developer could modify the interface for the smartphone (eg, use one line SELECT) if they want it to take less space, so there is no need to throw SIZE out.

2) Again, if a design decision, it might be argued that the basic functionality of a select element is to allow the user to choose one of the option elements, and that basic functionality is retained even is SIZE is ignored. But this argument also holds no water:

It is ridiculous to suggest that if the "basic functionality" of a tag is met, independent of the attributes, everything is fine. If that were true, what other attributes might webkit be comfortable with throwing out next? The following screenshot shows one example of many that could be cited (any analytical page using <select size>) where the webkit smartphone ignoring SIZE is destructive, basically makes the interface unusable. Furthermore, SELECT can do a lot more than "choose one". Take a close look below, you will see that it actually can let the user select a group of option elements, through programming the DOM, so there is more functionality to SIZE that many realize:

http://www.ehdp.com/vw-ajx/img02-bb1.htm

The bottom line is that, if a "design decision", it breaks HTML functionality, and destroys just about any real-world web page using <select size>, so it needs to be corrected. No decisions are set in stone, any decent organization reviews and corrects bad past decisions.

----- <select size> is OK non-webkit smartphone browsers, so webkit is "out of step"

The opera and firefox browsers were tested on smartphone devices, display select size perfectly, and provide the needed functionality, allow use of pages with <select size>. So far the webkit smartphone browsers are the "odd man out", the only ones to ignore SIZE, and thus destroy the page functionality. This makes the webkit smartphone browsers NOT compliant with HTML. Internet Explorer on the iphone has not been tested yet, but a message has been posted to a newsgroup asking someone to check the HTML 4 test page. Here is example of perfect performance with <select size> of opera on ipod:

http://www.ehdp.com/out/ipod-opera-select-is-perfect.png

9. Keywords

Possible keywords to consider, to be determined by whoever reviews this bug report:

AndroidHitList - The bug shows up in the google browser for galaxy player.

EasyFix - Since <size select> works perfectly on the webkit desktop browsers, it may be an easy fix to correct the error in the smartphone browser implementations.

GoogleBug - The bug shows up in the google browser for galaxy player.

InChromiumBugs - I do not know about submitting to the chromium bug database. Could you please advise?

NativeListBox - I have no idea exactly what this is, but it might be related to the SELECT tag, so I listed it in case relevant.

W3Ctest - http://www.w3.org/MarkUp/Test/HTML401/current/tests/17_6-BF-01.html is the w3c test to confirm the bug.

Hi

I had solve this problem .
The solve method as follow 
In Source\WebCore\rendering\RenderListBox.cpp
have define minSize as follow .

const int minSize = 4;

modified the minSize from 4 to 2 , this problem is OK

I will make a patch for it .

Created attachment 215143 [details]
The option size of select tag.

[WebKit Commit Bot]

Comment on attachment 215143 [details]
The option size of select tag.

Rejecting attachment 215143 [details] from review queue.

[e-mail] does not have reviewer permissions according to http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/common/config/contributors.json.

- If you do not have reviewer rights please read http://webkit.org/coding/contributing.html for instructions on how to use bugzilla flags.

- If you have reviewer rights please correct the error in Tools/Scripts/webkitpy/common/config/contributors.json by adding yourself to the file (no review needed).  The commit-queue restarts itself every 2 hours.  After restart the commit-queue will correctly respect your reviewer rights.

[WebKit Commit Bot]

Comment on attachment 215143 [details]
The option size of select tag.

Rejecting attachment 215143 [details] from commit-queue.

[e-mail] does not have committer permissions according to http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/common/config/contributors.json.

- If you do not have committer rights please read http://webkit.org/coding/contributing.html for instructions on how to use bugzilla flags.

- If you have committer rights please correct the error in Tools/Scripts/webkitpy/common/config/contributors.json by adding yourself to the file (no review needed).  The commit-queue restarts itself every 2 hours.  After restart the commit-queue will correctly respect your committer rights.

[Dan Goldman]

I originally reported the bug. I do not edit the webkit source code. But from my programming knowledge as a professional C developer, I am EXTREMELY skeptical that changing minSize from 4 to 2 in RenderListBox.cpp as recently suggested would solve this particular problem. I think it is a premature conclusion. Just my opinion... If I am proved wrong, I would be very happy.

I am hopeful there is a simple solution. The desktop webkit implementations of <select size> work perfectly, so it would seem to me the smartphone webkit implementations should be able to also work perfectly.

I appreciate the webkit developers looking, in a systemic fashion, at this bug that I reported. Please let me know any way I might assist.

[Dan Goldman]

Created attachment 215232 [details]
Screenshot of http://www.w3.org/MarkUp/Test/HTML401/current/tests/17_6-BF-01.html on ipod safari browser

The screenshot shows that the Safari browser fails the HTML 4.01 "Test for assertion 17.6-3". This is the bug that I am reporting, that <select size> is broken on webkit smartphone browsers.

[Dan Goldman]

Created attachment 215238 [details]
Screenshot of http://www.w3.org/MarkUp/Test/HTML401/current/tests/17_6-BF-01.html on lumia 920 IE 10 browser

The screenshot shows that the Windows Phone Internet Explorer browser passes the HTML 4.01 "Test for assertion 17.6-3". I did not have this information when I posted the bug report. So <select size> displays and works perfectly on Opera, Firefox, and IE smartphone browsers, fails on webkit-based smartphone browsers.

[Dan Goldman]

Created attachment 215256 [details]
Screenshot of http://www.w3.org/MarkUp/Test/HTML401/current/tests/17_6-BF-01.html on kindle fire hd silk browser

The screenshot shows that the Silk browser fails the HTML 4.01 "Test for assertion 17.6-3". This is the bug that I am reporting, that <select size> is broken on webkit smartphone browsers.

[Dan Goldman]

Created attachment 215260 [details]
Screenshot of http://www.w3.org/MarkUp/Test/HTML401/current/tests/17_6-BF-01.html on galaxy player 4.2 default browser

The screenshot shows that the default browser on the galaxy player 4.2 fails the HTML 4.01 "Test for assertion 17.6-3". This is the bug that I am reporting, that <select size> is broken on webkit smartphone browsers. I cannot tell exactly what this browser is, because there is no title or "about" screen for the browser that indicates the exact kind. When I access a web site using the galaxy player 4.2 default browser, the apache server log says: "Mozilla/5.0 (Linux; U; Android 2.3.6; en-us; YP-GI1 Build/GINGERBREAD) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1" as the entry. This is pretty impossible for me to interpret, except that I can see it says AppleWebKit so I can tell it is relevant to this bug report.

[Daniel Bates]

This bug represents a browser-vendor-specific design decision and is not a bug with respect to the WebKit OpenSource project. Please file a bug/feature request in the appropriate browser vendor forum with regards to this issue. For iOS, please submit a feature request at <http://bugreport.apple.com>.

You can file a new issue for Chrome at <http://bugs.chromium.org>. I'm unclear where to file a bug report for the Amazon Silk browser. From briefly searching Google I found a forum post that suggest going through Amazon's customer support page to report a bug: <http://www.amazon.com/forum/kindle%20customer%20service%20q%20and%20a?_encoding=UTF8&cdForum=Fx1GLDPZMNR1X53&cdThread=Tx3VSJAB5ZXZ62V>. Following directions similar to the forum comment I found: <http://www.amazon.com/gp/help/customer/display.html/ref=hp_navbox_kspot_ksupport_img?nodeId=200127470>. Notice there is a Contact Us button on the right side of the page.