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

Description Šime Vidas 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.
Comment 1 Šime Vidas 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>
Comment 2 Chris Dumez 2023-02-24 12:46:49 PST
Pull request: https://github.com/WebKit/WebKit/pull/10662
Comment 3 Lili Swan 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/
Comment 4 EWS 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.
Comment 5 Radar WebKit Bug Importer 2023-02-25 10:14:19 PST
<rdar://problem/105926915>
Comment 6 Alexey Proskuryakov 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.
Comment 7 Chris Dumez 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.
Comment 8 Ryosuke Niwa 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.