-
Notifications
You must be signed in to change notification settings - Fork 29.8k
Upstream changes necessary for text editing in flutter web #39344
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
Conversation
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.
I think this information could also be used for autocomplete on android, see https://developer.android.com/reference/android/view/autofill/AutofillManager.html#notifyViewEntered(android.view.View)
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.
Since the info is sent as a platform message, all platforms will be able to take advantage of it.
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.
What do you think of creating a class that contains all information pertaining to an editable? We could extend this class to include other data in the future without changing the signature of this method?
Having said that, we probably want to keep things that are updated on different schedules separate. For example, positioning and size are updated on every frame, but autocomplete might be scheduled based on user input. SemanticsNode is one example that contains everything in the world and I'm not sure I'm a fan of that design. We end up pushing way more data than we need on every frame.
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.
It is a layering violation for services to know about painting. Instead, the system channels here should probably only expose the primitive values, and leave interpreting text style to the views themselves.
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.
| if(kIsWeb) { | |
| if (kIsWeb) { |
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.
Suggestion: Change comment to : Optimize by skipping the update if nothing has changed since last paint.
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.
onPaint is not a good name for this. RenderEditable does not paint when scrolled inside a parent scrollable. We may stop depending on painting altogether and find another method for updating the TextConnection, but the name will stick. I'm now thinking if the proper fix does involve having this callback here at all, and so adding it now will lead to a future breaking change 🤔
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.
What do you think of creating a class that contains all information pertaining to an editable? We could extend this class to include other data in the future without changing the signature of this method?
Having said that, we probably want to keep things that are updated on different schedules separate. For example, positioning and size are updated on every frame, but autocomplete might be scheduled based on user input. SemanticsNode is one example that contains everything in the world and I'm not sure I'm a fan of that design. We end up pushing way more data than we need on every frame.
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.
Is renderBoxSize a good name? How about editableBoxSize?
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.
How can this method guarantee that the values are taken from the render box? This method is public and developers can use it however they like. I think instead we should say that the size is used to size the editable box.
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.
Can we use transform.storage?
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.
I wonder if we should have a more descriptive and less platform-dependent kUsePlatformContextMenu or something. I imagine this being used in other situations, such as links and images, and on other platforms, such as Flutter for desktop.
f58e0c8 to
d0ee01d
Compare
|
It looks like this was merged while the tree was red. Please do not merge while the tree is red unless you are specifically merging a change to turn the tree green (https://github.com/flutter/flutter/wiki/Tree-hygiene#overview), as it complicates the job trying to get the tree green again. |
|
Sorry, that was my bad. Should I revert or keep? |
|
No need to revert - just FYI for the future. Thanks! |
|
@mdebbar It looks like the gallery transition perf test started failing around when you landed this. Can you see if you can figure out if it was this commit, or if not, which commit it was? |
|
hello |
|
Hello @mdebbar, @tvolkert, @xster, @Hixie Error message:
Another exception is about |
|
Thanks @aleor, I am actively working on it now. |
|
Hello @nturgut , I have experienced the situation above on Android, though the exceptions are swallowed and can only be observed if you run the app in debug mode on VS Code and mark the "All Exceptions" checkbox on debug panel. Besides that, this bug was introduced by this pull request. I'm circumventing it commenting out the |
In flutter web, we place a transparent DOM input field right on top of flutter's text field. This enables us to leverage things like context menu, cut/copy/paste, spellcheck and autocomplete from the browser.
To make that possible, we need the framework to send more information about the text field such as text styling, location, size, transform matrix, etc. This PR provides that information in the form of platform messages.
This PR also disables flutter's text field toolbar when running inside the browser because we want to show the browser's native toolbar and context menu.
Fixes #39343