Skip to content

Introduce MaxLengthEnforcement#68086

Merged
AlexV525 merged 87 commits intoflutter:masterfrom
AlexV525:update-length-limiting-formatter
Dec 9, 2020
Merged

Introduce MaxLengthEnforcement#68086
AlexV525 merged 87 commits intoflutter:masterfrom
AlexV525:update-length-limiting-formatter

Conversation

@AlexV525
Copy link
Member

@AlexV525 AlexV525 commented Oct 14, 2020

Description

In #63754 a new behavior about the composing TextEditingValue for the LengthLimitingTextInputFormatter was introduced, but it's not optional which somehow breaks the original behavior for the limiting.

This PR:

  • brings a new enum MaxLengthEnforcement.
  • deprecate maxLengthEnforced that exist in text fields.

New behaviors for different platforms:

  • Android, Windows: MaxLengthEnforcement.enforced. The native behavior of these platforms is enforced. The composing will be handled by the IME while users are entering CJK characters.
  • iOS: MaxLengthEnforcement.truncateAfterCompositionEnds. iOS has no default behavior and it requires users implement the behavior themselves. Allow the composition to exceed to avoid breaking CJK input.
  • Web, macOS, linux, fuchsia: MaxLengthEnforcement.truncateAfterCompositionEnds. These platforms allow the composition to exceed by default.

Related Issues

Fixes #67898 .

Tests

I added the following tests:

  • Grouped max length tests in editable text test.
  • MaxLengthEnforcement tests in cupertino/material text field tests.
  • "enforced composing truncated" in editable text test.
  • "composing range removed if it's overflowed the truncated value's length" in editable text test.
  • truncate behaviors on different platforms.

Checklist

Before you create this PR, confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

  • I read the Contributor Guide and followed the process outlined there for submitting PRs.
  • I signed the CLA.
  • I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
  • I read the Tree Hygiene wiki page, which explains my responsibilities.
  • I updated/added relevant documentation (doc comments with ///).
  • All existing and new tests are passing.
  • The analyzer (flutter analyze --flutter-repo) does not report any problems on my PR.
  • I am willing to follow-up on review comments in a timely manner.

Breaking Change

Did any tests fail when you ran them? Please read Handling breaking changes.

@flutter-dashboard flutter-dashboard bot added framework flutter/packages/flutter repository. See also f: labels. work in progress; do not review labels Oct 14, 2020
@google-cla google-cla bot added the cla: yes label Oct 14, 2020
@goderbauer goderbauer requested a review from justinmc October 14, 2020 21:40
@AlexV525
Copy link
Member Author

Should we move these tests into text formatter test?

@justinmc
Copy link
Contributor

I think I'm in favor of this solution to the problems discussed in #67898. Limiting length with/without composing characters both seem to have valid uses, so it makes sense to let developers choose which they want. I'm also interested in what @LongCatIsLooong thinks.

Maybe instead of a bool, this should be combined with maxLengthEnforced and made into an enum? Like maxLengthEnforcement or something like that. Then deprecate maxLengthEnforced. Then we don't have to worry about both bools being true, and it's future-proof if more cases appear later.

@AlexV525
Copy link
Member Author

Maybe instead of a bool, this should be combined with maxLengthEnforced and made into an enum?

Before, maxLengthEnforced in TextField controls whether a LengthLimitingTextInputFormatter will be inserted or not. If not, it will be only an error tip when the value reached limitation.

If it can convert to enum, I prefer maxLengthEnforcement too, and there will be three values for it:

  • none or regular: Same as the current truncate behavior, as default.
  • warningOnly: Same as maxLength == x && maxLengthEnforced == false.
  • truncateComposing: Apply length limit on composing value too.

Does it seems valid?

Copy link
Contributor

@LongCatIsLooong LongCatIsLooong left a comment

Choose a reason for hiding this comment

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

This doesn't seem to be a breaking change? See https://github.com/flutter/flutter/wiki/Tree-hygiene#1-determine-if-your-change-is-a-breaking-change, the tests seem to be passing?

@AlexV525
Copy link
Member Author

This doesn't seem to be a breaking change? See https://github.com/flutter/flutter/wiki/Tree-hygiene#1-determine-if-your-change-is-a-breaking-change, the tests seem to be passing?

It was suggested from #67898 (comment)

@LongCatIsLooong
Copy link
Contributor

@AlexV525 Ah I meant this PR per se is not breaking (at least customer_testing is not failing).

Making maxLengthEnforced an enum sounds good to me.

none or regular: Same as the current truncate behavior, as default.
I think none is already covered by setting maxLength to null or -1?

@AlexV525
Copy link
Member Author

I think none is already covered by setting maxLength to null or -1?

So maybe regular is more fit for the case, which means truncated while it's not composing.

@AlexV525
Copy link
Member Author

Ah I meant this PR per se is not breaking (at least customer_testing is not failing).

😕 Then how should we announce this...? Or not?

@LongCatIsLooong
Copy link
Contributor

LongCatIsLooong commented Oct 16, 2020

confused Then how should we announce this...? Or not?

Sorry I got ahead of myself in that issue. If we deprecate the maxLengthEnforced parameter then it will be a breaking change (when we eventually remove the parameter it's going to break code that's still using it).

@AlexV525 AlexV525 marked this pull request as draft October 16, 2020 13:25
@AlexV525
Copy link
Member Author

AlexV525 commented Oct 17, 2020

Both TextField and CupertinoTextField have maxLengthEnforced, is it okay to put the enum in editable_text.dart ? Maybe text_formatter.dart ?

@LongCatIsLooong
Copy link
Contributor

Yeah makes sense to put it in text_formatter.dart since that's where the length limiting formatter is.

Copy link
Contributor

@justinmc justinmc left a comment

Choose a reason for hiding this comment

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

Mostly just some quick formatting and docs fixes. I think the behavior looks great now, thanks for making those changes.

@justinmc
Copy link
Contributor

justinmc commented Dec 7, 2020

In order to get around the customer test failures (which are coming from the gallery), this is what we'll have to do:

  1. Remove the @Deprecated flags from this PR, then merge it when it goes green.
  2. Submit a PR in the Flutter gallery to migrate from maxLengthEnforced to maxLengthEnforcement here.
  3. Submit another PR here to add back the deprecation.

@AlexV525
Copy link
Member Author

AlexV525 commented Dec 8, 2020

There is another serious issue with characters calculation when I was testing "Composing range handled correctly when it's overflowed" in editable text tests.

image

The calculation of newValue.text is resulting a wrong length, which should be 6. This will cause the test fail but not related to the current PR. /cc @LongCatIsLooong @justinmc

Previously the test won't failed because the range is completely overflowed, but when I tried with a shorter text this happened. So I'm going to keep the current working test and separate this to another issue or PR.

@justinmc
Copy link
Contributor

justinmc commented Dec 8, 2020

Which test is it that fails like that? I don't follow exactly why it's failing now.

In general though I think that's a good plan, if this is unrelated. You should create a new issue and then add a TODO in the code with a link to the issue.

@AlexV525
Copy link
Member Author

AlexV525 commented Dec 8, 2020

Which test is it that fails like that? I don't follow exactly why it's failing now.

In general though I think that's a good plan, if this is unrelated. You should create a new issue and then add a TODO in the code with a link to the issue.

"Composing range handled correctly when it's overflowed" in editable_text_tests. I've saw some related issues before, I'll file a new one if it doesn't exist.

@fluttergithubbot
Copy link
Contributor

This pull request is not suitable for automatic merging in its current state.

  • Please get at least one approved review before re-applying this label. Reviewers: If you left a comment approving, please use the "approve" review action instead.

Copy link
Contributor

@justinmc justinmc left a comment

Choose a reason for hiding this comment

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

LGTM 👍

Copy link
Contributor

@LongCatIsLooong LongCatIsLooong left a comment

Choose a reason for hiding this comment

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

I think this is a good idea! All the input methods I tried on Android adhere to Gboard's convention. Left a few comments about nits regarding documentation.

Copy link
Contributor

@LongCatIsLooong LongCatIsLooong left a comment

Choose a reason for hiding this comment

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

Sorry for the confusion. LGTM with nits.

@AlexV525
Copy link
Member Author

AlexV525 commented Dec 9, 2020

Thanks for everyone that make efforts to this PR to make it solid! It's a huge change and hope it can truly solve composing issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

f: cupertino flutter/packages/flutter/cupertino repository f: material design flutter/packages/flutter/material repository. framework flutter/packages/flutter repository. See also f: labels.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

TextField doesn't respect maxLength limit

7 participants