fix: iOS Autocorrect strips formatting by reporting wrong dataType

[redstar504]

fixes #4801

A troubling issue has been identified with the iOS keyboard's autocorrect behavior and how it affects text formatting.

When a user selects a word prediction, or, when the operating system injects an autocorrected word (such as when typing its and not including the apostrophe), the data transfer type is incorrectly reported as text/html. This does not reflect the actual content, as the payload only contains plain text.

Addressing this issue involves a very straightforward validation to ensure the presence of element nodes within the parsed DOM when the data type is reported as text/html, before proceeding with inserting the DOM nodes.

My solution simply checks for the presence of element nodes in the parsed DOM using querySelector('*'). An alternative condition, Array.from(dom.body.childNodes).some(node => node.nodeType === 1) could be considered; however querySelector offers a more concise expression.

Since iOS reports both text/plain and text/html data types for it's keyboard corrections, this case falls back to text/plain and works properly. My only concern is if there could be some data transfers that might contain only plain text while reporting only text/html. Perhaps we could condition for those and fall through to the text/plain handler if no DOM nodes exist as a result of the predicate that checks for elements.

In my opinion, this simple fix takes the editor from unusable to usable on iOS devices. See the before and after videos.

Before:

autocorrect-before.mp4

After:

autocorrect-after.mp4

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
lexical	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 15, 2025 11:20pm
lexical-playground	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 15, 2025 11:20pm

[ivailop7]

If this the assumed correct fix, could we please add a test and fix the tests, since they appear to be failing across the board.

[ivailop7]

This seems to work correctly now.

[BPreisner]

@ivailop7 this still doesn’t work for me on iOS 18 https://playground.lexical.dev:

ScreenRecording_12-23-2024.11-49-27_1.mov

And it works perfectly on the env deployed for this PR: https://lexical-playground-kpe12sqos-fbopensource.vercel.app/

[amanharwara]

Yeah, this is still an issue. Very easily reproducible using the playground on iOS (i tried with a iOS 16.7 device and also a iOS 18.2 simulator). Can this PR be re-opened?

[github-actions]

size-limit report 📦

Path	Size
lexical - cjs	28.99 KB (0%)
lexical - esm	28.81 KB (0%)
@lexical/rich-text - cjs	37.96 KB (-0.01% 🔽)
@lexical/rich-text - esm	30.91 KB (-0.07% 🔽)
@lexical/plain-text - cjs	36.54 KB (+0.08% 🔺)
@lexical/plain-text - esm	28.15 KB (0%)
@lexical/react - cjs	39.77 KB (0%)
@lexical/react - esm	32.26 KB (0%)

[etrepum]

This PR still needs to be fixed before it can be accepted. If no progress is made on the failing tests and lack of new tests in the next few weeks then it will be closed again.

[BPreisner]

@redstar504 are you still around to take a look on these failing tests? 🙏🏼

[redstar504]

I've updated my solution with a different approach that passes all of the tests.

To provide a bit of an explanation, when an autocorrection or word prediction is chosen in Safari, the browser pastes the word and includes two meta types which are handled by our clipboard code: text/plain and text/html. This is strange behavior on behalf of Safari, because the pasted word is only ever plain text.

Our clipboard handling code treats the plain text as HTML, and the result of both the plaintext and HTML handling code running simultaneously causes the formatting to be stripped. To avoid this, I added a check that simply prevents the HTML handling code from running if there is also text/plain content, and the content is the same.

It's a pretty simple solution. The original checked for any DOM nodes in the pasted HTML before executing the insertion code (to make sure it's actually HTML). That one broke the tests because some of the tests paste plain text as text/html, or paste text that includes meta HTML without any nodes.

[BPreisner]

Awesome @redstar504 🚀 I can confirm that it's working as I would expect on the env deployed. @etrepum could you please review? 🙏🏼

[etrepum]

The code looks fine but it would be better if there was a test that shows that it does what it is trying to do

[BPreisner]

@redstar504 would you mind adding a test? :) We are close to have this issue fixed on main :P Let me know if you don't have enough time so I can try to write one

[redstar504]

Added a test.

[etrepum]

Thank you for taking the time to write a test!

[BPreisner]

Awesome guys, thanks for fixing this @redstar504!