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
Fix that RenderEditable (TextField) ignores offset in painting, making text selections shifted when offset is nonzero #109287
Conversation
It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie on the #hackers channel in Chat (don't just cc him here, he won't see it! He's on Discord!). If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix? Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. |
As discussed on Discord, the approach in this PR looks good to me. Please tag me or request a review from me when you finish the tests. |
@justinmc New tests added and passed :) |
@justinmc Hi, is there any updates? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
Thanks for fixing this and for adding the test! Just one nit below and a question. Maybe we can make it more clear where the 14
value comes from in the test if possible, otherwise no big deal.
|
||
final List<LeaderLayer> leaderLayers = context.pushedLayers.whereType<LeaderLayer>().toList(); | ||
expect(leaderLayers, hasLength(1), reason: '_paintHandleLayers will paint a LeaderLayer'); | ||
expect(leaderLayers.single.offset, const Offset(0, 14) + paintOffset, reason: 'offset should respect paintOffset'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: 0.0 and 14.0 for doubles.
Also, where does that 14 come from exactly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, where does that 14 come from exactly?
LeaderLayer(link: endHandleLayerLink, offset: endPoint + offset),
That endPoint
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is fontsize. I have make it more explicit now. (Will see whether CI is happy)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CI looks happy about that
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That looks much more obvious about what's happening, thank you!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
…ing, making text selections shifted when offset is nonzero (flutter/flutter#109287)
…g, making text selections shifted when offset is nonzero (flutter/flutter#109287)
I will start adding tests once flutter team thinks this PR is acceptable, since I am not sure whether the team like to fix it, and if the team does not like it I will not waste time on it :)
When implementing
RenderBox.paint
, we know we should respect theoffset
parameter. However, even though_paintContents
respects it, the_paintHandleLayers
does not - instead it completely ignores the offset parameter. This is logically wrong as it does not respect the definition and requirements of the function.Luckily (or unluckily), currently it does not have visible harm yet. This is because
RenderEditable
is used by_Editable
and future byEditableText
. And, the_Editable
's ancestors widgets do not provide any offset (because the widgets in the same Layer paint child without shifting). Thus,offset
parameter is always zero in the current version of Flutter.However, I am still proposing this PR because of the following reasons:
paint
), so by definition it is a bug and we should fix it.assert(offset==Offset.zero)
to enforce it.)RenderEditable
(since it is public), and even copy some of the source code and hack it (e.g. me). With their customizations, it is highly possible that the offset is no longer always zero, then they will find suddenly the text selections shifted weirdly. (Disclaimer: That is my case, and why I find this bug)I have not come up with a way to make tests about this, because
_Editable
is private, and as mentioned above, it is logically wrong but not visible now.However, this PR does not add any new logic, so making existing tests pass IMHO may be sufficient.
Close #109289
If you had to change anything in the flutter/tests repo, include a link to the migration guide as per the breaking change policy.
P.S. https://discord.com/channels/608014603317936148/608018585025118217/1006808038914654218
Pre-launch Checklist
///
).If you need help, consider asking for advice on the #hackers-new channel on Discord.