-
Notifications
You must be signed in to change notification settings - Fork 6k
[Linux] take first steps towards testable text input #33661
Conversation
This allows passing an offscreen window for testing purposes.
Keep track of registered message handlers and allow tests to simulate receiving messages.
robert-ancell
left a comment
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.
Code LGTM.
cbracken
left a comment
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 with a minor suggestion.
|
Looks like there's a legitimate test failure to fix in |
|
@jpnurmi Any updates on the test failures? |
GdkOffscreenWindow requires display & screen which is a problem in headless mode. Luckily, we don't really need a window instance in tests because its only passed as a client window to the IM context which will be mocked out when we get to tests that depend on it.
|
I was silly and ignored the harmless warnings from GdkWindow but the warnings would become a problem when made fatal. Luckily, we don't really need a window instance in the text input tests because it's only passed as a client window to the IM context which will be mocked out when we get to tests that depend on it. |
This PR is a continuation of flutter#33111 and includes necessary changes to test the `TextInputType.setClient()` platform channel call. Testing the actual text input flow requires a mock IM context that will follow in a separate PR. * [Linux] pass GdkWindow instead of FlView to FlTextInputPlugin * [Linux] add MockBinaryMessenger::ReceiveMessage() * [Linux] add test for TextInputType.setClient * Drop the offscreen window GdkOffscreenWindow requires display & screen which is a problem in headless mode. Luckily, we don't really need a window instance in tests because its only passed as a client window to the IM context which will be mocked out when we get to tests that depend on it.
|
I've pushed the next step: #34186 |
This PR is a continuation of #33111 and includes necessary changes to test the
TextInputType.setClient()platform channel call. Testing the actual text input flow requires a mock IM context that will follow in a separate PR.Pre-launch Checklist
///).