Introduce MaxLengthEnforcement#68086
Conversation
|
Should we move these tests into text formatter test? |
|
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 |
Before, If it can convert to enum, I prefer
Does it seems valid? |
There was a problem hiding this comment.
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) |
|
@AlexV525 Ah I meant this PR per se is not breaking (at least customer_testing is not failing). Making
|
So maybe |
😕 Then how should we announce this...? Or not? |
Sorry I got ahead of myself in that issue. If we deprecate the |
|
Both |
|
Yeah makes sense to put it in |
justinmc
left a comment
There was a problem hiding this comment.
Mostly just some quick formatting and docs fixes. I think the behavior looks great now, thanks for making those changes.
|
In order to get around the customer test failures (which are coming from the gallery), this is what we'll have to do:
|
|
There is another serious issue with characters calculation when I was testing "Composing range handled correctly when it's overflowed" in editable text tests. The calculation of 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. |
|
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 |
|
This pull request is not suitable for automatic merging in its current state.
|
LongCatIsLooong
left a comment
There was a problem hiding this comment.
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.
LongCatIsLooong
left a comment
There was a problem hiding this comment.
Sorry for the confusion. LGTM with nits.
|
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. |

Description
In #63754 a new behavior about the composing
TextEditingValuefor theLengthLimitingTextInputFormatterwas introduced, but it's not optional which somehow breaks the original behavior for the limiting.This PR:
MaxLengthEnforcement.maxLengthEnforcedthat exist in text fields.New behaviors for different platforms:
MaxLengthEnforcement.enforced. The native behavior of these platforms is enforced. The composing will be handled by the IME while users are entering CJK characters.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.MaxLengthEnforcement.truncateAfterCompositionEnds. These platforms allow the composition to exceed by default.Related Issues
Fixes #67898 .
Tests
I added the following tests:
MaxLengthEnforcementtests in cupertino/material text field tests.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.///).flutter analyze --flutter-repo) does not report any problems on my PR.Breaking Change
Did any tests fail when you ran them? Please read Handling breaking changes.