Get Element Tag Name case inconsistencies

[juliandescottes]

Specification for Get Element Tag Name

Let qualified name be the result of getting element's tagName IDL attribute.

Specification for tagName

The tagName getter steps are to return this’s HTML-uppercased qualified name.

Based on this we should return an uppercase string. However historically, Chrome and Firefox have returned lowercase strings, while Safari was returning uppercase strings. This was illustrated by the test test_get_element_tag_name in. https://wpt.fyi/results/webdriver/tests/classic/get_element_tag_name/get.py?label=master&label=experimental&aligned&q=tests%2Fclassic%2Fget_element_tag_name which incorrectly expected a lowercase string until web-platform-tests/wpt#58756 and servo/servo#43673

For Firefox we started changing the implementation to align with the test at https://bugzilla.mozilla.org/show_bug.cgi?id=2026697. While doing so we also updated another wdspec test with wrong expectations: https://wpt.fyi/results/webdriver/tests/classic/get_element_tag_name/user_prompts.py?label=master&label=experimental&aligned&q=%2Fclassic%2Fget_element_tag_name%2Fuser_prompts.py

But due to regressions in existing 3rd party tests, we rolled back the change and we should probably discuss if we want to change the behavior or update the spec, either to add a Note that some implementations are incorrectly returning lowercase, or to say that the implementations can return either uppercase or lowercase. Ideally of course it would be better to just return uppercase everywhere, but at this point I'm not sure there is a clean path to update this for Chrome and Firefox without breaking a lot of consumers.

[whimboo]

Based on the wpt.fyi results for test_get_element_tag_name, only Safari and Servo return the tag name as is and don't lowercase its value. So we should get some feedback from Apple folks about Safari for alignment across browsers.

CC'ing @gsnedders, @burg

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed Get Element Tag Name case inconsistencies.

The full IRC log of that discussion

<jgraham> Topic: Get Element Tag Name case inconsistencies
<jgraham> github: https://github.com//issues/1956
<tidoust> jdescottes: A WebDriver classic topic.
<tidoust> ... We have Get Element Tag Name that's supposed to return upper case, but some implementations have returned lowercase, while others have returned uppercase.
<Euclid> q+
<tidoust> ... Should we rather try to change the spec to return lowercase? Or should we make it a bit more vague and say it can be fine to return either?
<whimboo> q+
<jgraham> ack next
<tidoust> Euclid: First time here!
<tidoust> ... I was wondering why Servo wasn't passing this test. Only Safari is doing it correctly. Is that what we're discussing here?
<tidoust> [yes]
<jgraham> ack next
<tidoust> whimboo: Would be good to get feedback from Apple.
<tidoust> ... Hopefully, they'll get back to us.
<tidoust> ... Regarding Servo, it shouldn't be a problem. Chrome and Firefox have been returning lowercase for years.
<tidoust> ... I don't know if tag names can mix lowercase and uppercase characters.
<jdescottes> q+
<jgraham> ack next
<tidoust> jdescottes: Whether it's JS APIs or DOM, it's always exposed as uppercase.
<orkon> q+
<jgraham> ack next
<AutomatedTester> q+
<tidoust> orkon: Trying to check why we return lowercase. To me, we should align with Web APIs, and find a way to roll this out. Do we know any client that specifically rely on this behavior and that we would break?
<jgraham> q+
<jgraham> ack next
<tidoust> ack AutomatedTester
<tidoust> AutomatedTester: A lot of it is historical. We had to normalize it and decided to normalize it to lowercase. If we go from lowercase to uppercase, most projects probably handle that on the client side so end users would not notice the difference.
<jgraham> ack next
<tidoust> jgraham: DOM does not seem to do case folding for non-HTML elements.
<tidoust> ... I think it's absolutely certain that someone is doing a test somewhere that expects the behavior.
<tidoust> ... The question is really about what the Webkit people think, as it seems difficult to change.
<tidoust> ... Hopefully, they are willing to change it.
<orkon> q+
<jgraham> ack next
<tidoust> orkon: If there is inconsistency between implementations and products are already dealing with this, do we need to worry about it?
<jgraham> q+
<tidoust> ... Maybe we could leave it as-is.
<jdescottes> q+
<jgraham> ack next
<tidoust> jgraham: I don't love leaving it as-is.
<tidoust> ... At the moment, the spec says that Chrome and Firefox are wrong.
<tidoust> ... And for new implementers like Servo, it would be good if the spec told them what to do.
<tidoust> ... We absolutely could change the spec to a SHOULD level requirement, and note historical implementations to explain the differences.
<jgraham> ack next
<tidoust> ... It's accurate, although not ideal. But if nobody is willing to change, that might be the best we can get.
<orkon> q+
<tidoust> jdescottes: Back to examples of things that break. We had one regression entry, I believe. But just an internal test relying on this API and expecting lowercase.
<jgraham> q+
<jgraham> ack next
<tidoust> ... I would also assume that, since Safari has always returned uppercase, any client that works cross-browsers should already handle the inconsistency.
<tidoust> orkon: I would follow the HTML spec, and ship with a flag so that people can update at their leisure. And then after a year, we can remove the flag, or rollback the change.
<jgraham> ack next
<tidoust> jgraham: My concern is not broken clients, but individual tests broken.
<tidoust> ... We could try doing it behind a flag. It's very hard to get people to notice that there will be a breaking change in the future.
<tidoust> ... We could try to do something here. I'm skeptical of our abilities to making the change stick.
<jgraham> q?
<tidoust> jgraham: Next step is to get feedback from the Webkit people.

[burg]

It's not a problem to switch safaridriver behavior and the spec. Seems to have the least impact.