Bug 252900

Summary: HTML maxlength attribute treats emoji of string length 11 as length 1
Product: WebKit Reporter: Šime Vidas <sime.vidas>
Component: FormsAssignee: Chris Dumez <cdumez>
Status: RESOLVED FIXED    
Severity: Normal CC: ap, bramus, cdumez, darin, mmaxfield, rniwa, tahakhan.studio, webkit-bug-importer, wenson_hsieh
Priority: P2 Keywords: InRadar
Version: Safari 16   
Hardware: Mac (Intel)   
OS: macOS 13   
See Also: https://github.com/web-platform-tests/wpt/pull/38708
Attachments:
Description Flags
Test page none

Šime Vidas
Reported 2023-02-24 06:41:55 PST
Created attachment 465151 [details] 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.
Attachments
Test page (360 bytes, text/html)
2023-02-24 06:41 PST, Šime Vidas 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Šime Vidas
Comment 1 2023-02-24 06:43:04 PST
Comment on attachment 465151 [details] 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>
Chris Dumez
Comment 2 2023-02-24 12:46:49 PST
Pull request: https://github.com/WebKit/WebKit/pull/10662
Lili Swan
Comment 3 2023-02-25 03:54:13 PST
This issue i am also having in safari but as far as now the issue is fixed and tested on https://yt2mp3.id/es/
EWS
Comment 4 2023-02-25 10:13:42 PST
Committed 260838@main (9743d10df7bc): <https://commits.webkit.org/260838@main> Reviewed commits have been landed. Closing PR #10662 and removing active labels.
Radar WebKit Bug Importer
Comment 5 2023-02-25 10:14:19 PST
<rdar://problem/105926915>
Alexey Proskuryakov
Comment 6 2023-02-27 13:23:31 PST
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.
Chris Dumez
Comment 7 2023-02-27 13:28:00 PST
(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.
Ryosuke Niwa
Comment 8 2023-02-27 23:51:37 PST
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.
Note You need to log in before you can comment on or make changes to this bug.