accessing innerText of a <select> element does not return expected text
Reported by
j...@mozilla.com,
Aug 10 2016
|
|||||
Issue description
Chrome Version : 52.0.2743.116 (Official Build) (64-bit)
URLs (if applicable) : see testcase below
Other browsers tested:
Add OK or FAIL, along with the version, after other browsers where you
have tested this issue:
Safari: FAIL - Version 9.0.2 (9537.86.3.9.1)
Firefox: FAIL - see https://bugzilla.mozilla.org/show_bug.cgi?id=1290937
IE: untested
What steps will reproduce the problem?
Consider the testcase:
data:text/html,<select><option>foo</option></select>
Result: $('option').innerText returns "foo"
Result: $('select').innerText returns ""
What is the expected result?
The innerText of a parent element should include the innerText of its child(ren).
What happens instead?
The <select> returns empty for innerText, even though it clearly does "contain" the text of its child <option> element.
Note that as there is no real spec for innerText, it's not entirely clear what "correct" behavior should be; but I believe the current Chrome (and Safari) behavior of returning empty for the <select> is unintuitive and unhelpful.
In https://bugzilla.mozilla.org/show_bug.cgi?id=1290937 I am proposing to fix innerText for <option> elements in Firefox, and would like to fix this <select> issue at the same time, both because it seems the most reasonable behavior and because it will be the natural result of the <option> fix.
,
Aug 12 2016
http://rocallahan.github.io/innerText-spec/index.html#intro If the intention of innerText is "rendered text", select.innerText should return an empty string, and option.innerText should return an empty string in this case, right? So the bug is option.innerText. http://w3c-test.org/innerText/getter.html has such test case.
,
Aug 12 2016
,
Aug 12 2016
Why should option.innerText return an empty string? The <option> renders its text. Also, note that there are existing pages that depend on option.innerText returning the option's text (not an empty string); see https://bugzilla.mozilla.org/show_bug.cgi?id=1290937, filed against Firefox because its lack of support for this breaks page functionality. So while roc's draft spec doesn't call out <option> as one of the elements that _should_ return its text (like <button>), in practice web-compat requires this and the spec should be updated to reflect this. I opened an issue on this: https://github.com/rocallahan/innerText-spec/issues/5. The <select> test cases currently in http://w3c-test.org/innerText/getter.html are therefore wrong, I believe, and we propose to update them.
,
Aug 17 2016
I meant option.innerText in a popup-menu <select> should have returned an empty string because options are not rendered in the page. However, I confirmed Edge was compatible with Google Chrome. select.innerText is empty, and optino.innerText is not empty. Personally, I wanted Firefox to ship innerText as an alias of textContent.
,
Aug 18 2016
tkent, which version of Edge? I got a different result in at least IE9..11 and Edge 13 and 14, see: https://github.com/rocallahan/innerText-spec/issues/5#issuecomment-240668213 http://logs.glob.uno/?c=freenode%23whatwg&s=18+Aug+2016&e=18+Aug+2016#c1003174 onward
,
Aug 18 2016
,
Aug 23 2016
> tkent, which version of Edge? I got a different result in at least IE9..11 and Edge 13 and 14, see: I tested it with EdgeHTML 14.14393. https://www.irccloud.com/pastebin/wp99E4RY/ in the IRC log also showed select.innerText in Edge 14 returned "". > (Dup of https://bugs.chromium.org/p/chromium/issues/detail?id=424578 ?) 424578 is about option.innerText. It's a regression and not compatible with IE/Edge now. So we should fix Issue 424578 . Change the status to ExternalDependency. This should be solved in the standard body first.
,
Oct 3 2016
Bulk-adding Hotlist-Interop to bugs filed by other browser vendors based on the summary. Feel free to remove if this issue doesn't actually reflect a difference in behavior between engines. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by tkonch...@chromium.org
, Aug 11 2016