252900 2023-02-24 06:41:55 -0800 HTML maxlength attribute treats emoji of string length 11 as length 1 2023-02-27 23:51:37 -0800 1 1 1 Unclassified WebKit Forms Safari 16 Mac (Intel) macOS 13 RESOLVED FIXED https://github.com/web-platform-tests/wpt/pull/38708 InRadar P2 Normal --- 1 sime.vidas cdumez ap bramus cdumez darin mmaxfield rniwa tahakhan.studio webkit-bug-importer wenson_hsieh oldest_to_newest 1936508 0 465151 sime.vidas 2023-02-24 06:41:55 -0800 Created attachment 465151 Test page Steps to reproduce: 1. Open attached test page in Safari 2. Copy the rendered family emoji and paste it into the <input maxlength=10> field What happened: The emoji fully appears inside the input. You will be able to paste the emoji up to 10 times. What should have happened: The emoji should have been altered. In Chrome and Firefox, one of the children in the depicted family disappears. The full emoji has a string size of 11, so it shouldn’t fully fit into an <input> with a maxlength of 10. It seems that Safari’s maxlength implementation treats all emoji as length 1. 1936509 1 465151 sime.vidas 2023-02-24 06:43:04 -0800 Comment on attachment 465151 Test page ><!DOCTYPE html> > ><html> > <head> > <meta charset="utf-8" /> > <meta name="viewport" content="width=device-width" /> > <title>emoji input maxlength test</title> > <style> > * { > font-size: 2rem; > margin: 0.1em; > } > </style> > </head> > <body> > <p>👨‍👩‍👧‍👦</p> > <input maxlength="10" /> > </body> ></html> 1936619 2 cdumez 2023-02-24 12:46:49 -0800 Pull request: https://github.com/WebKit/WebKit/pull/10662 1936742 3 tahakhan.studio 2023-02-25 03:54:13 -0800 This issue i am also having in safari but as far as now the issue is fixed and tested on https://yt2mp3.id/es/ 1936775 4 ews-feeder 2023-02-25 10:13:42 -0800 Committed 260838@main (9743d10df7bc): <https://commits.webkit.org/260838@main> Reviewed commits have been landed. Closing PR #10662 and removing active labels. 1936776 5 webkit-bug-importer 2023-02-25 10:14:19 -0800 <rdar://problem/105926915> 1937172 6 ap 2023-02-27 13:23:31 -0800 The behavior that we chose was very intentional, and I don't see how it "makes Web developers' life more difficult than it needs to be." The decision was made in bug 120030, and I don't see anything to have changed that would make us change our opinion. 1937174 7 cdumez 2023-02-27 13:28:00 -0800 (In reply to Alexey Proskuryakov from comment #6) > The behavior that we chose was very intentional, and I don't see how it > "makes Web developers' life more difficult than it needs to be." > > The decision was made in bug 120030, and I don't see anything to have > changed that would make us change our opinion. Willfully ignoring the specification and not other aligning with every other major browser is harmful to the Web. This is a serious interoperability issue which has been reported several times over the years. This was also discussed as a spec issue and they decided to keep the spec as is after discussing with other browser vendors, despite our feedback. The ship for others to align with us here has sailed. 1937307 8 rniwa 2023-02-27 23:51:37 -0800 While our choice may have been intentional for this ill-conceived feature, the reality of the situation is that other browser vendors are unwilling to change their behaviors, and we keep getting bug reports about this behavior difference. Given we can't rid of maxlength, the path of the least resistance is for WebKit to match other browsers. 465151 2023-02-24 06:41:55 -0800 2023-02-24 06:41:55 -0800 Test page test-page.html text/html 360 sime.vidas PCFET0NUWVBFIGh0bWw+Cgo8aHRtbD4KICA8aGVhZD4KICAgIDxtZXRhIGNoYXJzZXQ9InV0Zi04 IiAvPgogICAgPG1ldGEgbmFtZT0idmlld3BvcnQiIGNvbnRlbnQ9IndpZHRoPWRldmljZS13aWR0 aCIgLz4KICAgIDx0aXRsZT5lbW9qaSBpbnB1dCBtYXhsZW5ndGggdGVzdDwvdGl0bGU+CiAgICA8 c3R5bGU+CiAgICAgICogewogICAgICAgIGZvbnQtc2l6ZTogMnJlbTsKICAgICAgICBtYXJnaW46 IDAuMWVtOwogICAgICB9CiAgICA8L3N0eWxlPgogIDwvaGVhZD4KICA8Ym9keT4KICAgIDxwPvCf kajigI3wn5Gp4oCN8J+Rp+KAjfCfkaY8L3A+CiAgICA8aW5wdXQgbWF4bGVuZ3RoPSIxMCIgLz4K ICA8L2JvZHk+CjwvaHRtbD4K