<rdar://problem/54780864>
Created attachment 377545 [details] Patch
Created attachment 377580 [details] Patch
Created attachment 377589 [details] Tweak ChangeLog wording
We are having this very same blocking issue. Here's what we were about to send to the Feedback Tracker, but thankfully I found this here. You can find reproductions attached. --- Blocker: Caret not shown on inputs within transformed elements in Safari and WkWebview # Issue identification: The caret does not show in inputs that are within transformed (translation, etc) elements. # Applies to: All devices running iOS 13.0.X and 13.1.X betas released so far. (Tested in various iPhones, iPod) # Provided projects A. A HTML file that can be served and opened in Safari directly, showing the issue. B. A Xcode project to build and test on iOS 13, showing the issue. # Reproduction steps: 1. Click the input on the first page, the caret will display along with the keyboard. 2. Click the "Switch page" button above. 3. Click the input on the second page, the caret will not display along with the keyboard.
Created attachment 377607 [details] Standalone HTML reproduction
Created attachment 377608 [details] Xcode Project WKWebview reproduction
Created attachment 377609 [details] Safari screen capture
Created attachment 377610 [details] WK screen capture
In addition, this may be related or not, but the input interaction menu does now show up on the fields where the caret is broken. It's impossible to select all, paste, copy, etc.
Comment on attachment 377589 [details] Tweak ChangeLog wording Clearing flags on attachment: 377589 Committed r249296: <https://trac.webkit.org/changeset/249296>
All reviewed patches have been landed. Closing bug.
(In reply to Pierre-Luc Auclair from comment #4) > We are having this very same blocking issue. Here's what we were about to > send to the Feedback Tracker, but thankfully I found this here. You can find > reproductions attached. Thanks for the bug report and test case, Pierre! I tried out your test app, and observed that the bug still reproduces even after the above change. I’m currently working on a fix for your test case, which I’m tracking in <https://bugs.webkit.org/show_bug.cgi?id=201317>.