Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SuperTextField] Fix text capitalization configuration (Resolves #1617) #1619

Merged

Conversation

angelosilvestre
Copy link
Collaborator

[SuperTextField] Fix text capitalization configuration. Resolves #1617

Passing a TextInputConfiguration with a textCapitalization different from TextCapitalization.none has no effect.

Two issues are involved on this:

  1. ImeAttributedTextEditingController.updateTextInputConfiguration doesn't take a TextCapitalization.

When we added support for passing a TextInputConfiguration to SuperTextField, we kept updateTextInputConfiguration taking individual arguments instead of a TextInputConfiguration to avoid a breaking change.

I suggest we make that breaking change and take a TextInputConfiguration as argument. Otherwise, we need to take all TextInputConfiguration properties in this method.

  1. We are re-attaching to the IME on every call to didUpdateWidget if we have a imeConfiguration.

The reason is that we are comparing only widget.imeConfiguration != oldWidget.imeConfiguration. This compares the references, not the imeConfiguration properties. So, if we don't use a const imeConfiguration, in each build we get a different instance, which causes us to re-attach to the IME.

This PR changes the comparison to also compare all TextInputConfiguration properties, by using an extension method.

// Change the brightness to rebuild the widget
// and re-attach to the IME.
brightnessNotifier.value = Brightness.light;
await tester.pumpAndSettle();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you need to settle here?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pump is enough. Updated.

child: ListenableBuilder(
listenable: rebuildSignal,
builder: (context, child) {
// Explicitly avoid using const to ensure that each build
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about instead of the careful non-const approach, you declare two different variables with the same IME config value and you switch from one to the other?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated.

@@ -35,3 +37,42 @@ enum WebPlatformOverride {
/// Configuration to run the app as if we are on web.
web,
}

extension TextInputConfigurationExtensions on TextInputConfiguration {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does TextInputConfiguration really not implement a custom ==? If not, can you file a Flutter issue to at least put this on their radar?

Let's name these extensions more specifically. We may never add another extension to them, so let's say what they really do, e.g., TextInputConfigurationEquivalency

Also, let's place these in a location that we don't export from the package. These exist for an internal detail of super_editor. I'd rather not be on the hook for maintaining these extensions, and the Flutter team might eventually implement this behavior directly.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@angelosilvestre
Copy link
Collaborator Author

@matthew-carroll The test failures are the same as the previous PR.

readOnly == other.readOnly &&
obscureText == other.obscureText &&
autocorrect == other.autocorrect &&
autofillConfiguration.isEquivalentTo(other.autofillConfiguration) &&
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanted to point one thing out that might be relevant. I checked the API for AutofillConfiguration and it seems to include the current TextEditingValue. That suggests to me that every time the user types a character, deletes a character, or moves the caret, the overall TextInputConfiguration will be seen as unequal. Do you also see it that way? If so, do we really want that configuration getting sent every time those things happen?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As this is a configuration, I would expect that AutofillConfiguration stores only the initial TextEditingValue without updating it at every keystroke, but the docs aren't clear about that and I've never used the AutofillConfiguration before.

I don't think we want to consider the TextInputConfiguration unequal at every TextEditingValue. Should I remove it from the comparison?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the safest thing is probably to remove it. Please add a comment mentioning that we don't include it in the comparison, and why we don't.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated.

Copy link
Contributor

@matthew-carroll matthew-carroll left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@matthew-carroll matthew-carroll merged commit 67c0332 into superlistapp:main Nov 27, 2023
6 of 11 checks passed
@angelosilvestre angelosilvestre deleted the 1617_text_capitalization branch November 27, 2023 23:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[SuperEditor][SuperTextField][Mobile] Unable to change TextCapitalization of the text field
2 participants