[lexical] Bug Fix: account for Apple WebView in setManagedLineBreak#7854
[lexical] Bug Fix: account for Apple WebView in setManagedLineBreak#7854etrepum merged 3 commits intofacebook:mainfrom
setManagedLineBreak#7854Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
etrepum
left a comment
There was a problem hiding this comment.
Interesting, it looks like the jsdom implementation might look enough like webkit for this change to break the unit test expectations? I think it's fine if the expectation changes, but the tests should pass before we merge
|
I think this is probably good, but there is some chance that our e2e tests on mac+chromium are not catching some regression where we expect Chrome to also be IS_APPLE_WEBKIT on macOS. We might want to note that as a breaking change. Here's an example Chrome userAgent: |
|
Are there any cases where Chrome on macOS is expected to be |
etrepum
left a comment
There was a problem hiding this comment.
It looks like you're right, I just missed that at first glance because it's on another line. I think this should be good to go then
Description
Currently,
setManagedLineBreakonly accounts forIS_IOSandIS_SAFARIwhen applying the WebKit-specific hack for line breaks.However, in Apple’s WebView environments (such as Tauri with wry on macOS),
IS_APPLE_WEBKITistruebut not considered, which can lead to inconsistent line break rendering and cursor behavior.This PR updates the logic so that the WebKit-specific hack also applies when
IS_APPLE_WEBKITis true. This ensures consistent behavior across iOS Safari, standalone Safari, and embedded Apple WebView environments.Before
before.mp4
After
after.mp4
decoratorline break type is now handled the same way as in Safari.