Fix cursor moving while typing quickly and autocorrection triggered in controlled single line TextInput on iOS (New Arch) #46970

NickGerleman · 2024-10-11T08:22:05Z

Summary:
This one is a bit of a doozy...

During auto-correct in UITextField (used for single line TextInput) iOS will mutate the buffer in two parts, non-atomically. After the first part, after iOS triggers textFieldDidChange, selection is in the wrong position. If we set full new AttributedText at this point, we propagate the incorrect cursor position, and it is never restored.

In the common case, where we are not mutating text in the controlled component, we shouldn't need to be setting AttributedString in the first place, and we do have an equality comparison there currently. But it is defeated because attributes are not identical. There are a few sources of that:

NSParagraphStyle is present in backing input, but not the AttributedString we are setting.
Backing text has an NSShadow with no color (does not render) not in the AttributedText
Event emitter attributes change on each update, and new text does not inherit the attributes.

The first two are part of the backing input typingAttributes, even if we set a dictionary without them. To solve for them, we make attribute comparison insensitive to the attribute values in a default initialized control. There is code around here fully falling back to attribute insensitive comparison, which we would ideally fix to instead role into this "effective" attribute comparison.

The event emitter attributes being misaligned is a real problem. We fix in a couple ways.

We treat the attribute values as equal if the backing event emitter is the same
We preserve attributes that we already set and want to expand as part of typingAttributes
We set paragraph level event emitter as a default attribute so the first typed character receives it

After these fixes, scenario in facebook/react-native-website#4247 no longer repros in new arch. Typing in debug build also subjectively seems faster? (we are not doing second invalidation of the control on every keypress).

Changes which do mutate content may be susceptible to the same style of issue, though on web/react-dom in Chrome, this seems to not try to preserve selection at all if the selection is uncontrolled, so this seems like less of an issue.

I haven't yet looked at old arch, but my guess is we have similar issues there, and could be fixed in similar ways (though, we've been trying to avoid changing it as much as possible, and 0.76+ has new arch as default, so not sure if worth fixing in old impl as well if this is very long running issue).

Changelog:
[iOS][Fixed] - Fix cursor moving in iOS controlled single line TextInput on Autocorrection (New Arch)

Differential Revision: D64121570

facebook-github-bot · 2024-10-11T08:22:13Z

This pull request was exported from Phabricator. Differential Revision: D64121570

…n controlled single line TextInput on iOS (New Arch) (facebook#46970) Summary: This one is a bit of a doozy... During auto-correct in UITextField (used for single line TextInput) iOS will mutate the buffer in two parts, non-atomically. After the first part, selection is in the wrong position. If we set full new AttributedText at this point, we propagate the incorrect cursor position, and it is never restored. Afaict, there is not a public way to queue our own mutation until after this happens. In the common case, where we are not mutating text in the controlled component, we shouldn't need to be setting AttributedString in the first place, and we do have an equality comparison there currently. But it is defeated because attributes are not identical. There are a few sources of that: 1. NSParagraphStyle is present in backing input, but not the AttributedString we are setting. 2. Backing text has an NSShadow with no color (does not render) not in the AttributedText 3. Event emitter attributes change on each update, and new text does not inherit the attributes. The first two are part of the backing input `typingAttributes`, even if we set a dictionary without them. To solve for them, we make attribute comparison insensitive to the attribute values in a default initialized control. There is code around here fully falling back to attribute insensitive comparison, which we would ideally fix to instead role into this "effective" attribute comparison. The event emitter attributes being misaligned is a real problem. We fix in a couple ways. 1. We treat the attribute values as equal if the backing event emitter is the same 2. We preserve attributes that we already set and want to expand as part of typingAttributes 3. We set paragraph level event emitter as a default attribute so the first typed character receives it After these fixes, scenario in facebook/react-native-website#4247 no longer repros in new arch. Changes which do mutate content may be susceptible to the same style of issue, though on web/`react-dom` in Chrome, this seems to not try to preserve selection at all if the selection is uncontrolled, so this seems like less of an issue. I haven't yet looked at old arch, but my guess is we have similar issues there, and could be fixed in similar ways (so, we've been trying to avoid changing it as much as possible, and 0.76+ has new arch as default, so not sure if worth fixing in old impl as well if this is very long running issue). Changelog: [iOS][Fixed] - Fix cursor moving in iOS controlled single line TextInput on Autocorrection (New Arch) Differential Revision: D64121570

facebook-github-bot · 2024-10-11T08:25:25Z

This pull request was exported from Phabricator. Differential Revision: D64121570

…n controlled single line TextInput on iOS (New Arch) (facebook#46970) Summary: This one is a bit of a doozy... During auto-correct in UITextField (used for single line TextInput) iOS will mutate the buffer in two parts, non-atomically. After the first part, after iOS triggers `textFieldDidChange`, selection is in the wrong position. If we set full new AttributedText at this point, we propagate the incorrect cursor position, and it is never restored. In the common case, where we are not mutating text in the controlled component, we shouldn't need to be setting AttributedString in the first place, and we do have an equality comparison there currently. But it is defeated because attributes are not identical. There are a few sources of that: 1. NSParagraphStyle is present in backing input, but not the AttributedString we are setting. 2. Backing text has an NSShadow with no color (does not render) not in the AttributedText 3. Event emitter attributes change on each update, and new text does not inherit the attributes. The first two are part of the backing input `typingAttributes`, even if we set a dictionary without them. To solve for them, we make attribute comparison insensitive to the attribute values in a default initialized control. There is code around here fully falling back to attribute insensitive comparison, which we would ideally fix to instead role into this "effective" attribute comparison. The event emitter attributes being misaligned is a real problem. We fix in a couple ways. 1. We treat the attribute values as equal if the backing event emitter is the same 2. We preserve attributes that we already set and want to expand as part of typingAttributes 3. We set paragraph level event emitter as a default attribute so the first typed character receives it After these fixes, scenario in facebook/react-native-website#4247 no longer repros in new arch. Typing in debug build also subjectively seems faster? (we are not doing second invalidation of the control on every keypress). Changes which do mutate content may be susceptible to the same style of issue, though on web/`react-dom` in Chrome, this seems to not try to preserve selection at all if the selection is uncontrolled, so this seems like less of an issue. I haven't yet looked at old arch, but my guess is we have similar issues there, and could be fixed in similar ways (so, we've been trying to avoid changing it as much as possible, and 0.76+ has new arch as default, so not sure if worth fixing in old impl as well if this is very long running issue). Changelog: [iOS][Fixed] - Fix cursor moving in iOS controlled single line TextInput on Autocorrection (New Arch) Differential Revision: D64121570

facebook-github-bot · 2024-10-11T09:37:09Z

This pull request was exported from Phabricator. Differential Revision: D64121570

…n controlled single line TextInput on iOS (New Arch) (facebook#46970) Summary: This one is a bit of a doozy... During auto-correct in UITextField (used for single line TextInput) iOS will mutate the buffer in two parts, non-atomically. After the first part, after iOS triggers `textFieldDidChange`, selection is in the wrong position. If we set full new AttributedText at this point, we propagate the incorrect cursor position, and it is never restored. In the common case, where we are not mutating text in the controlled component, we shouldn't need to be setting AttributedString in the first place, and we do have an equality comparison there currently. But it is defeated because attributes are not identical. There are a few sources of that: 1. NSParagraphStyle is present in backing input, but not the AttributedString we are setting. 2. Backing text has an NSShadow with no color (does not render) not in the AttributedText 3. Event emitter attributes change on each update, and new text does not inherit the attributes. The first two are part of the backing input `typingAttributes`, even if we set a dictionary without them. To solve for them, we make attribute comparison insensitive to the attribute values in a default initialized control. There is code around here fully falling back to attribute insensitive comparison, which we would ideally fix to instead role into this "effective" attribute comparison. The event emitter attributes being misaligned is a real problem. We fix in a couple ways. 1. We treat the attribute values as equal if the backing event emitter is the same 2. We preserve attributes that we already set and want to expand as part of typingAttributes 3. We set paragraph level event emitter as a default attribute so the first typed character receives it After these fixes, scenario in facebook/react-native-website#4247 no longer repros in new arch. Typing in debug build also subjectively seems faster? (we are not doing second invalidation of the control on every keypress). Changes which do mutate content may be susceptible to the same style of issue, though on web/`react-dom` in Chrome, this seems to not try to preserve selection at all if the selection is uncontrolled, so this seems like less of an issue. I haven't yet looked at old arch, but my guess is we have similar issues there, and could be fixed in similar ways (though, we've been trying to avoid changing it as much as possible, and 0.76+ has new arch as default, so not sure if worth fixing in old impl as well if this is very long running issue). Changelog: [iOS][Fixed] - Fix cursor moving in iOS controlled single line TextInput on Autocorrection (New Arch) Differential Revision: D64121570

facebook-github-bot · 2024-10-11T12:11:28Z

This pull request was exported from Phabricator. Differential Revision: D64121570

…n controlled single line TextInput on iOS (New Arch) (facebook#46970) Summary: Fixes facebook#44157 This one is a bit of a doozy... During auto-correct in UITextField (used for single line TextInput) iOS will mutate the buffer in two parts, non-atomically. After the first part, after iOS triggers `textFieldDidChange`, selection is in the wrong position. If we set full new AttributedText at this point, we propagate the incorrect cursor position, and it is never restored. In the common case, where we are not mutating text in the controlled component, we shouldn't need to be setting AttributedString in the first place, and we do have an equality comparison there currently. But it is defeated because attributes are not identical. There are a few sources of that: 1. NSParagraphStyle is present in backing input, but not the AttributedString we are setting. 2. Backing text has an NSShadow with no color (does not render) not in the AttributedText 3. Event emitter attributes change on each update, and new text does not inherit the attributes. The first two are part of the backing input `typingAttributes`, even if we set a dictionary without them. To solve for them, we make attribute comparison insensitive to the attribute values in a default initialized control. There is code around here fully falling back to attribute insensitive comparison, which we would ideally fix to instead role into this "effective" attribute comparison. The event emitter attributes being misaligned is a real problem. We fix in a couple ways. 1. We treat the attribute values as equal if the backing event emitter is the same 2. We set paragraph level event emitter as a default attribute so the first typed character receives it After these fixes, scenario in facebook/react-native-website#4247 no longer repros in new arch. Typing in debug build also subjectively seems faster? (we are not doing second invalidation of the control on every keypress). Changes which do mutate content may be susceptible to the same style of issue, though on web/`react-dom` in Chrome, this seems to not try to preserve selection at all if the selection is uncontrolled, so this seems like less of an issue. I haven't yet looked at old arch, but my guess is we have similar issues there, and could be fixed in similar ways (though, we've been trying to avoid changing it as much as possible, and 0.76+ has new arch as default, so not sure if worth fixing in old impl as well if this is very long running issue). Changelog: [iOS][Fixed] - Fix cursor moving in iOS controlled single line TextInput on Autocorrection (New Arch) Differential Revision: D64121570

facebook-github-bot · 2024-10-14T21:00:20Z

This pull request was exported from Phabricator. Differential Revision: D64121570

facebook-github-bot · 2024-10-14T21:05:51Z

This pull request was exported from Phabricator. Differential Revision: D64121570

efstathiosntonas · 2024-10-15T04:47:47Z

@NickGerleman hi, pleaaaaaaase try to fix Paper too, there are huge projects out there that will take some extra time to transition to Fabric. Thank you!

gedu · 2024-10-15T09:28:18Z

@NickGerleman hey, I found the same thing, related with attributes, I created a PR to fix other cases, do you think this can fix those too? Expensify/App#17153, #27693, #29572, #42792

I know my proposal also fix this autocorrection: #39385

…riggered in controlled single line TextInput on iOS (New Arch) (facebook#46970) Summary: Fixes facebook#44157 This one is a bit of a doozy... During auto-correct in UITextField (used for single line TextInput) iOS will mutate the buffer in two parts, non-atomically. After the first part, after iOS triggers `textFieldDidChange`, selection is in the wrong position. If we set full new AttributedText at this point, we propagate the incorrect cursor position, and it is never restored. In the common case, where we are not mutating text in the controlled component, we shouldn't need to be setting AttributedString in the first place, and we do have an equality comparison there currently. But it is defeated because attributes are not identical. There are a few sources of that: 1. NSParagraphStyle is present in backing input, but not the AttributedString we are setting. 2. Backing text has an NSShadow with no color (does not render) not in the AttributedText 3. Event emitter attributes change on each update, and new text does not inherit the attributes. The first two are part of the backing input `typingAttributes`, even if we set a dictionary without them. To solve for them, we make attribute comparison insensitive to the attribute values in a default initialized control. There is code around here fully falling back to attribute insensitive comparison, which we would ideally fix to instead role into this "effective" attribute comparison. The event emitter attributes being misaligned is a real problem. We fix in a couple ways. 1. We treat the attribute values as equal if the backing event emitter is the same 2. We set paragraph level event emitter as a default attribute so the first typed character receives it After these fixes, scenario in facebook/react-native-website#4247 no longer repros in new arch. Typing in debug build also subjectively seems faster? (we are not doing second invalidation of the control on every keypress). Changes which do mutate content may be susceptible to the same style of issue, though on web/`react-dom` in Chrome, this seems to not try to preserve selection at all if the selection is uncontrolled, so this seems like less of an issue. I haven't yet looked at old arch, but my guess is we have similar issues there, and could be fixed in similar ways (though, we've been trying to avoid changing it as much as possible, and 0.76+ has new arch as default, so not sure if worth fixing in old impl as well if this is very long running issue). Changelog: [iOS][Fixed] - Fix cursor moving in iOS controlled single line TextInput on Autocorrection (New Arch) Reviewed By: philIip Differential Revision: D64121570

…n controlled single line TextInput on iOS (New Arch) (facebook#46970) Summary: Fixes facebook#44157 This one is a bit of a doozy... During auto-correct in UITextField (used for single line TextInput) iOS will mutate the buffer in two parts, non-atomically. After the first part, after iOS triggers `textFieldDidChange`, selection is in the wrong position. If we set full new AttributedText at this point, we propagate the incorrect cursor position, and it is never restored. In the common case, where we are not mutating text in the controlled component, we shouldn't need to be setting AttributedString in the first place, and we do have an equality comparison there currently. But it is defeated because attributes are not identical. There are a few sources of that: 1. NSParagraphStyle is present in backing input, but not the AttributedString we are setting. 2. Backing text has an NSShadow with no color (does not render) not in the AttributedText 3. Event emitter attributes change on each update, and new text does not inherit the attributes. The first two are part of the backing input `typingAttributes`, even if we set a dictionary without them. To solve for them, we make attribute comparison insensitive to the attribute values in a default initialized control. There is code around here fully falling back to attribute insensitive comparison, which we would ideally fix to instead role into this "effective" attribute comparison. The event emitter attributes being misaligned is a real problem. We fix in a couple ways. 1. We treat the attribute values as equal if the backing event emitter is the same 2. We set paragraph level event emitter as a default attribute so the first typed character receives it After these fixes, scenario in facebook/react-native-website#4247 no longer repros in new arch. Typing in debug build also subjectively seems faster? (we are not doing second invalidation of the control on every keypress). Changes which do mutate content may be susceptible to the same style of issue, though on web/`react-dom` in Chrome, this seems to not try to preserve selection at all if the selection is uncontrolled, so this seems like less of an issue. I haven't yet looked at old arch, but my guess is we have similar issues there, and could be fixed in similar ways (though, we've been trying to avoid changing it as much as possible, and 0.76+ has new arch as default, so not sure if worth fixing in old impl as well if this is very long running issue). Changelog: [iOS][Fixed] - Fix cursor moving in iOS controlled single line TextInput on Autocorrection (New Arch) Reviewed By: philIip Differential Revision: D64121570

facebook-github-bot · 2024-10-15T15:59:36Z

This pull request was exported from Phabricator. Differential Revision: D64121570

facebook-github-bot · 2024-10-15T16:09:56Z

This pull request was exported from Phabricator. Differential Revision: D64121570

…n controlled single line TextInput on iOS (New Arch) (facebook#46970) Summary: Fixes facebook#44157 This one is a bit of a doozy... During auto-correct in UITextField (used for single line TextInput) iOS will mutate the buffer in two parts, non-atomically. After the first part, after iOS triggers `textFieldDidChange`, selection is in the wrong position. If we set full new AttributedText at this point, we propagate the incorrect cursor position, and it is never restored. In the common case, where we are not mutating text in the controlled component, we shouldn't need to be setting AttributedString in the first place, and we do have an equality comparison there currently. But it is defeated because attributes are not identical. There are a few sources of that: 1. NSParagraphStyle is present in backing input, but not the AttributedString we are setting. 2. Backing text has an NSShadow with no color (does not render) not in the AttributedText 3. Event emitter attributes change on each update, and new text does not inherit the attributes. The first two are part of the backing input `typingAttributes`, even if we set a dictionary without them. To solve for them, we make attribute comparison insensitive to the attribute values in a default initialized control. There is code around here fully falling back to attribute insensitive comparison, which we would ideally fix to instead role into this "effective" attribute comparison. The event emitter attributes being misaligned is a real problem. We fix in a couple ways. 1. We treat the attribute values as equal if the backing event emitter is the same 2. We set paragraph level event emitter as a default attribute so the first typed character receives it After these fixes, scenario in facebook/react-native-website#4247 no longer repros in new arch. Typing in debug build also subjectively seems faster? (we are not doing second invalidation of the control on every keypress). Changes which do mutate content may be susceptible to the same style of issue, though on web/`react-dom` in Chrome, this seems to not try to preserve selection at all if the selection is uncontrolled, so this seems like less of an issue. I haven't yet looked at old arch, but my guess is we have similar issues there, and could be fixed in similar ways (though, we've been trying to avoid changing it as much as possible, and 0.76+ has new arch as default, so not sure if worth fixing in old impl as well if this is very long running issue). Changelog: [iOS][Fixed] - Fix cursor moving in iOS controlled single line TextInput on Autocorrection (New Arch) Reviewed By: javache, philIip Differential Revision: D64121570

facebook-github-bot · 2024-10-15T16:58:02Z

This pull request was exported from Phabricator. Differential Revision: D64121570

…n controlled single line TextInput on iOS (New Arch) (facebook#46970) Summary: Fixes facebook#44157 This one is a bit of a doozy... During auto-correct in UITextField (used for single line TextInput) iOS will mutate the buffer in two parts, non-atomically. After the first part, after iOS triggers `textFieldDidChange`, selection is in the wrong position. If we set full new AttributedText at this point, we propagate the incorrect cursor position, and it is never restored. In the common case, where we are not mutating text in the controlled component, we shouldn't need to be setting AttributedString in the first place, and we do have an equality comparison there currently. But it is defeated because attributes are not identical. There are a few sources of that: 1. NSParagraphStyle is present in backing input, but not the AttributedString we are setting. 2. Backing text has an NSShadow with no color (does not render) not in the AttributedText 3. Event emitter attributes change on each update, and new text does not inherit the attributes. The first two are part of the backing input `typingAttributes`, even if we set a dictionary without them. To solve for them, we make attribute comparison insensitive to the attribute values in a default initialized control. There is code around here fully falling back to attribute insensitive comparison, which we would ideally fix to instead role into this "effective" attribute comparison. The event emitter attributes being misaligned is a real problem. We fix in a couple ways. 1. We treat the attribute values as equal if the backing event emitter is the same 2. We set paragraph level event emitter as a default attribute so the first typed character receives it After these fixes, scenario in facebook/react-native-website#4247 no longer repros in new arch. Typing in debug build also subjectively seems faster? (we are not doing second invalidation of the control on every keypress). Changes which do mutate content may be susceptible to the same style of issue, though on web/`react-dom` in Chrome, this seems to not try to preserve selection at all if the selection is uncontrolled, so this seems like less of an issue. I haven't yet looked at old arch, but my guess is we have similar issues there, and could be fixed in similar ways (though, we've been trying to avoid changing it as much as possible, and 0.76+ has new arch as default, so not sure if worth fixing in old impl as well if this is very long running issue). Changelog: [iOS][Fixed] - Fix cursor moving in iOS controlled single line TextInput on Autocorrection (New Arch) Reviewed By: javache, philIip Differential Revision: D64121570

facebook-github-bot · 2024-10-15T23:34:06Z

This pull request has been merged in 36fd553.

react-native-bot · 2024-10-15T23:34:08Z

This pull request was successfully merged by @NickGerleman in 36fd553

^{When will my fix make it into a release? | How to file a pick request?}

ivan-moego · 2024-10-28T02:55:17Z

@NickGerleman hi, The RN version of expo51 used in our project is 0.74.5, and newArchEnabled is false. According to experience, it will take at least two months to upgrade to expo52 and RN0.76.0.
Our merchants have been troubled by this problem for a long time。
if we want to fix this problem in RN0.74.5 with newArchEnabled is false, how should we do it, can you give some ideas and pseudo-code? thank you!

…n controlled single line TextInput on iOS (New Arch) (#46970) Summary: Pull Request resolved: #46970 Fixes #44157 This one is a bit of a doozy... During auto-correct in UITextField (used for single line TextInput) iOS will mutate the buffer in two parts, non-atomically. After the first part, after iOS triggers `textFieldDidChange`, selection is in the wrong position. If we set full new AttributedText at this point, we propagate the incorrect cursor position, and it is never restored. In the common case, where we are not mutating text in the controlled component, we shouldn't need to be setting AttributedString in the first place, and we do have an equality comparison there currently. But it is defeated because attributes are not identical. There are a few sources of that: 1. NSParagraphStyle is present in backing input, but not the AttributedString we are setting. 2. Backing text has an NSShadow with no color (does not render) not in the AttributedText 3. Event emitter attributes change on each update, and new text does not inherit the attributes. The first two are part of the backing input `typingAttributes`, even if we set a dictionary without them. To solve for them, we make attribute comparison insensitive to the attribute values in a default initialized control. There is code around here fully falling back to attribute insensitive comparison, which we would ideally fix to instead role into this "effective" attribute comparison. The event emitter attributes being misaligned is a real problem. We fix in a couple ways. 1. We treat the attribute values as equal if the backing event emitter is the same 2. We set paragraph level event emitter as a default attribute so the first typed character receives it After these fixes, scenario in facebook/react-native-website#4247 no longer repros in new arch. Typing in debug build also subjectively seems faster? (we are not doing second invalidation of the control on every keypress). Changes which do mutate content may be susceptible to the same style of issue, though on web/`react-dom` in Chrome, this seems to not try to preserve selection at all if the selection is uncontrolled, so this seems like less of an issue. I haven't yet looked at old arch, but my guess is we have similar issues there, and could be fixed in similar ways (though, we've been trying to avoid changing it as much as possible, and 0.76+ has new arch as default, so not sure if worth fixing in old impl as well if this is very long running issue). Changelog: [iOS][Fixed] - Fix cursor moving in iOS controlled single line TextInput on Autocorrection (New Arch) Reviewed By: javache, philIip Differential Revision: D64121570 fbshipit-source-id: 2b3bd8a3002c33b68af60ffabeffe01e25c7ccfe

react-native-bot · 2024-11-12T19:14:53Z

This pull request was successfully merged by @NickGerleman in 40093d9

^{When will my fix make it into a release? | How to file a pick request?}

facebook-github-bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Oct 11, 2024

facebook-github-bot added fb-exported p: Facebook Partner: Facebook Partner labels Oct 11, 2024

NickGerleman force-pushed the export-D64121570 branch from 32dacc0 to 804bdb1 Compare October 11, 2024 08:25

NickGerleman changed the title ~~Fix cursor moving while typing quickly and autocorrection triggered in controlled single line TextInput on iOS (New Arch)~~ Fix comparison of AttributedStrings when setting UITextField attributedText from state Oct 11, 2024

NickGerleman changed the title ~~Fix comparison of AttributedStrings when setting UITextField attributedText from state~~ Fix cursor moving while typing quickly and autocorrection triggered in controlled single line TextInput on iOS (New Arch) Oct 11, 2024

NickGerleman force-pushed the export-D64121570 branch from 804bdb1 to 4bf3519 Compare October 11, 2024 09:37

NickGerleman force-pushed the export-D64121570 branch from 4bf3519 to cb9e1fe Compare October 11, 2024 12:11

tomekzaw mentioned this pull request Oct 14, 2024

Fast typing leads to noticeable hangs when blockquote is present on iOS with Fabric Expensify/react-native-live-markdown#101

Open

elicwhite mentioned this pull request Oct 14, 2024

Discourage using controlled inputs in React Native because they are broken facebook/react-native-website#4247

Closed

NickGerleman force-pushed the export-D64121570 branch from cb9e1fe to 86c90d9 Compare October 14, 2024 21:00

NickGerleman force-pushed the export-D64121570 branch from 86c90d9 to fae06e7 Compare October 14, 2024 21:05

NickGerleman force-pushed the export-D64121570 branch from fae06e7 to 43cff32 Compare October 15, 2024 15:59

NickGerleman force-pushed the export-D64121570 branch from 43cff32 to f639240 Compare October 15, 2024 16:09

NickGerleman force-pushed the export-D64121570 branch from f639240 to a78f7f3 Compare October 15, 2024 16:57

NickGerleman mentioned this pull request Oct 15, 2024

[IOS] Text replacement by dot after 2 spaces #39385

Closed

facebook-github-bot closed this in 36fd553 Oct 15, 2024

facebook-github-bot added the Merged This PR has been merged. label Oct 15, 2024

This was referenced Oct 16, 2024

issues with controlled TextInput with text replacement, "." shortcut on iOS #27693

Closed

TextInput without multiline breaks double tap space bar "." shortcut on iOS #42792

Closed

gedu mentioned this pull request Oct 16, 2024

[HOLD for #37437][$2000] Pressing space 2 times . appears in display name Expensify/App#17153

Open

6 tasks

cipolleschi mentioned this pull request Nov 19, 2024

[Codegen] Exclude unlinked libs from codegen #47712

Merged

cipolleschi mentioned this pull request Dec 9, 2024

[RN][Codegen] Better support filtering out non linked platforms #48183

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix cursor moving while typing quickly and autocorrection triggered in controlled single line TextInput on iOS (New Arch) #46970

Fix cursor moving while typing quickly and autocorrection triggered in controlled single line TextInput on iOS (New Arch) #46970

NickGerleman commented Oct 11, 2024 •

edited

Loading

facebook-github-bot commented Oct 11, 2024

facebook-github-bot commented Oct 11, 2024

facebook-github-bot commented Oct 11, 2024

facebook-github-bot commented Oct 11, 2024

facebook-github-bot commented Oct 14, 2024

facebook-github-bot commented Oct 14, 2024

efstathiosntonas commented Oct 15, 2024

gedu commented Oct 15, 2024

facebook-github-bot commented Oct 15, 2024

facebook-github-bot commented Oct 15, 2024

facebook-github-bot commented Oct 15, 2024

facebook-github-bot commented Oct 15, 2024

react-native-bot commented Oct 15, 2024

ivan-moego commented Oct 28, 2024 •

edited

Loading

react-native-bot commented Nov 12, 2024

Fix cursor moving while typing quickly and autocorrection triggered in controlled single line TextInput on iOS (New Arch) #46970

Fix cursor moving while typing quickly and autocorrection triggered in controlled single line TextInput on iOS (New Arch) #46970

Conversation

NickGerleman commented Oct 11, 2024 • edited Loading

facebook-github-bot commented Oct 11, 2024

facebook-github-bot commented Oct 11, 2024

facebook-github-bot commented Oct 11, 2024

facebook-github-bot commented Oct 11, 2024

facebook-github-bot commented Oct 14, 2024

facebook-github-bot commented Oct 14, 2024

efstathiosntonas commented Oct 15, 2024

gedu commented Oct 15, 2024

facebook-github-bot commented Oct 15, 2024

facebook-github-bot commented Oct 15, 2024

facebook-github-bot commented Oct 15, 2024

facebook-github-bot commented Oct 15, 2024

react-native-bot commented Oct 15, 2024

ivan-moego commented Oct 28, 2024 • edited Loading

react-native-bot commented Nov 12, 2024

NickGerleman commented Oct 11, 2024 •

edited

Loading

ivan-moego commented Oct 28, 2024 •

edited

Loading