This may be the desired behavior, it is not how Mozilla or current Safari implementations display it though. I would think that if there is a valid #TEXT child that that should take priority over the LABEL value. <html><head></head> <body> <form> Should say bar (I think.) <select> <option label="foo">bar</option> </select> </form> </body> </html>
Confirmed; WinIE 6 also has the same behavior as Firefox and shipping Safari. BTW, attaching test cases to the bugs (rather than pasting inline) makes them somewhat easier to work on.
Created attachment 7725 [details] test case Same test case, as an attachment.
The regression was caused when we fixed bug 7255. That bug complained that the label was ignored altogether. We need to change RenderSelect::updateFromElement to use the label only when the text is empty.
Created attachment 7756 [details] patch, no change log or test case yet
I think the fix for this was accidently committed in r13955 together with the fix for bug 8437. Leaving the bug open for now since at least the change log still needs to be updated.
Oops!
I'll need to fix the change log and write a layout test.
I'm going to roll back my fix. The tests fast/forms/HTMLOptionElement_label0[1-5] make it clear that we researched this when we implemented this. Alexey says that IE 6 has the same behavior as Firefox, but these tests seem to indicate otherwise. More research is required.
I just tested with WinIE and my results match Alexey's. Those HTMLOptionElement tests are wrong. I have to fix them.
The good news is, we don't have to make new test cases -- just fix those old ones. But anyone can do this based on my patch, so I'm throwing this back to "unassigned". Be sure to test what happens when the element does have content, but it's all whitespace, or if the content has something other than plain text in it.
*** Bug 8617 has been marked as a duplicate of this bug. ***
I'm confused on what is the correct behaviour. I tested the test cases fast/forms/HTMLOptionElement_label0[1-5] in Safari and in FF, and they both render them the same. When I tested them in IE7 beta2, the handling is different. But according to the comment #8 IE and FF behave the same. This is not what I am seeing. I am testing with TOT Safari and FF 1.5.0.3
I have just re-tested with: Safari (Mac OS X 10.4.6) Mac Firefox 1.5.0.1 WinIE 6.0.2900.2180.xpsp_sp2_rtm.040803-2158 ToT WebKit r14501 Stock Safari, Firefox and WinIE gave the same results; ToT was different in each test. I don't have IE7.
Retested. Got the same results as Alexey. However, Win IE7beta7 does the same as TOT Safari. I wonder if IE are changing their behaviour. Which result is correct, IE6, Firefox & stock Safari or WinIE7 & TOT Safari?
<rdar://problem/4556767>
Created attachment 8468 [details] Patch Applied patch to new code base - original patch file has moved. Included ChangeLogs, updated test cases and 2 new test cases.
Comment on attachment 8468 [details] Patch r=me
Created attachment 8470 [details] updated with new test cases Only change from previous patch was adding the new test cases.
Comment on attachment 8470 [details] updated with new test cases r=me
Created attachment 8626 [details] only change to the patch was to remove tabs and replace with spaces Remove tabs and repace with spaces. Fixed alignment of braces, ie {, in test case. No other changes.
Comment on attachment 8626 [details] only change to the patch was to remove tabs and replace with spaces r=me again
Okay, after looking at the HTML 4.01 spec it seems that is actually behaving correctly. LABLE has priority over the #TEXT content. However, in quirks mode this has not been the behavior as far as I could tell. In quirks mode Safari 2.0.3 uses the #TEXT contents. Firefox uses the #TEXT in either case.
Committed revision 14679.