NEW 257196
HTMLOptionElement text is impacted by 'Backslash-as-JPY' hack
https://bugs.webkit.org/show_bug.cgi?id=257196
Summary HTMLOptionElement text is impacted by 'Backslash-as-JPY' hack
Ahmad Saleem
Reported 2023-05-23 05:32:00 PDT
Hi Team, WebKit has 'Backslash-as-JPY' hack and it was removed from Blink. I noticed that we have 'WPT' test, which fail due to this hack: WPT Test Link: https://wpt.fyi/results/html/semantics/forms/the-option-element/option-text-backslash.html?label=master&label=experimental&aligned&q=option-text-backslash.html WPT Test Live Link: http://wpt.live/html/semantics/forms/the-option-element/option-text-backslash.html Blink Commit: https://src.chromium.org/viewvc/blink?view=revision&revision=159589 ^ Only doing partial merge of above to HTMLOptionElement (I also did for HTMLOptGroupElement). We pass the above testcase. ____ Changes in HTMLOptGroupElement.cpp (Line 121 onward): String HTMLOptGroupElement::groupLabelText() const { String itemText = attributeWithoutSynchronization(labelAttr); // In WinIE, leading and trailing whitespace is ignored in options and optgroups. We match this behavior. ______ Changes in HTMLOptionElement.cpp (Line 108 onward): String HTMLOptGroupElement::groupLabelText() const { String itemText = attributeWithoutSynchronization(labelAttr); // In WinIE, leading and trailing whitespace is ignored in options and optgroups. We match this behavior. ______ Just wanted to raise so we can track it.
Attachments
Alexey Proskuryakov
Comment 1 2023-05-23 08:49:52 PDT
I'd be very cautious about putting too much weight on Blink decisions in this area. Presumably Chrome on Windows effectively still has it through the behavior of Microsoft fonts. We'll need to evaluate the user impact ourselves.
Ahmad Saleem
Comment 2 2023-05-23 09:06:30 PDT
(In reply to Alexey Proskuryakov from comment #1) > I'd be very cautious about putting too much weight on Blink decisions in > this area. Presumably Chrome on Windows effectively still has it through the > behavior of Microsoft fonts. > > We'll need to evaluate the user impact ourselves. Just test on work laptop with windows and Chrome Stable, still pass this test, which might suggest that they are not following Microsoft’s font behavior.
Alexey Proskuryakov
Comment 3 2023-05-23 11:42:01 PDT
The font behavior is happening behind the scenes, so the test would pass, but the character visible to the user would be different between Windows and Mac Chrome. IIRC one also needs to be running Windows in Japanese to see the difference.
Ahmad Saleem
Comment 4 2023-05-23 14:36:19 PDT
(In reply to Alexey Proskuryakov from comment #3) > The font behavior is happening behind the scenes, so the test would pass, > but the character visible to the user would be different between Windows and > Mac Chrome. IIRC one also needs to be running Windows in Japanese to see the > difference. Fair point.. I don't have laptop machine to change / experiment with Japanese language. Can we ask someone from Sony team from win-cairo team to experiment on this testcase with Chrome? and see if this fails.
Anne van Kesteren
Comment 5 2023-05-25 08:48:57 PDT
Alexey, but wouldn't this create an inconsistency with other macOS/iOS applications? This assumes the website was either made on Windows with such a font and legacy encoding or made on macOS/iOS using Safari. And while it might visually work for that case, it seems that we end up creating a different node tree which I'd argue is even more surprising behavior and more likely to create real interoperability issues.
Alexey Proskuryakov
Comment 6 2023-05-25 13:11:48 PDT
The choice as I understand it is between everything being consistently wrong vs. getting the most common scenario (looking at the webpage) right, while the rest remains the same. Although I don't remember if we also do this correction when copying to the pasteboard - if we do, that covers pretty much all scenarios except for cross-platform tests. So I feel like the choice to preserve status quo is obvious as long as we believe that this is still somewhat common on the web.
Radar WebKit Bug Importer
Comment 7 2023-05-30 05:32:17 PDT
Anne van Kesteren
Comment 8 2023-05-31 09:36:10 PDT
Alexey pointed to https://github.com/w3c/csswg-drafts/issues/6848 which should probably be resolved before we do anything here. Given that it's an open issue we could meanwhile rename the tests to include .tentative to make it clear they are testing something that is not yet decided upon.
Note You need to log in before you can comment on or make changes to this bug.