I've noticed some errors that may be related to the text input plugin for multi view. After applying these changes to the canonical:foundation branch and adding a TextField widget to both the main window and the regular windows of the reference app, if I a focus the text field widget and then close the window (using Alt+F4 or clicking on the close button), sometimes I get the following error at message_codecs.dart:168:

Exception has occurred.
PlatformException (PlatformException(Internal Consistency Error, Text input is not available in Windows headless mode, null, null))

This issue wasn't introduced by this PR, as similar (though not identical) behavior can be observed in canonical:foundation.

Files changed in the reference app: ref_app_lib.zip

I've noticed some errors that may be related to the text input plugin for multi view. After applying these changes to the canonical:foundation branch and adding a TextField widget to both the main window and the regular windows of the reference app, if I a focus the text field widget and then close the window (using Alt+F4 or clicking on the close button), sometimes I get the following error at message_codecs.dart:168:

Exception has occurred.
PlatformException (PlatformException(Internal Consistency Error, Text input is not available in Windows headless mode, null, null))

This issue wasn't introduced by this PR, as similar (though not identical) behavior can be observed in canonical:foundation.

Files changed in the reference app: ref_app_lib.zip

So two things appear to be happening here:

1. This is a bad error message. The real issue is that we are unable to find the view. I will update the logging to reflect that and write a test for this case.
2. We're experiencing some sort of race. The framework asks the engine to TextInput.setClient. In the meantime, the window (and thus the view) gets destroyed. Hence, when we go to resolve the view later on from the provided ID, it is already destroyed. I'll see if there is anything that we can do about this, but it might just be an "expected" error.

LGTM from a text input standpoint. We already send the viewId as part of the TextInputConfiguration so this should just wire up. Is there an example app somewhere that I can use to test this out locally?

I have an example app that works with the multi window pull request. If you merge up this branch into foundation in canonical/flutter, then you can run the provided app like so:

flutter run --debug --local-engine-src-path C:/dev/flutter/engine/src/ --local-engine host_debug_unopt --local-engine-host host_debug_unopt .\lib\services\text_input\test.dart --enable-multi-window

(replacing my paths with your paths, and I added test.dart to the api example app for ease of use)

import 'package:flutter/material.dart';
import 'package:flutter/services.dart';

void main() {
  final RegularWindowController controller1 = RegularWindowController(size: const Size(640, 480));
  final RegularWindowController controller2 = RegularWindowController(size: const Size(640, 480));
  runWidget(ViewCollection(
    views: [
      RegularWindow(controller: controller1, child: MyApp()),
      RegularWindow(controller: controller2, child: MyApp()),
    ]
  ));
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Name Prompt',
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      home: NameInputScreen(),
    );
  }
}

class NameInputScreen extends StatefulWidget {
  @override
  _NameInputScreenState createState() => _NameInputScreenState();
}

class _NameInputScreenState extends State<NameInputScreen> {
  final TextEditingController _controller = TextEditingController();
  String? _name;

  void _submitName() {
    setState(() {
      _name = _controller.text;
    });
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: Text('Enter Your Name')),
      body: Padding(
        padding: const EdgeInsets.all(16.0),
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: [
            TextField(
              controller: _controller,
              decoration: InputDecoration(labelText: 'Name'),
            ),
            SizedBox(height: 16),
            ElevatedButton(
              onPressed: _submitName,
              child: Text('Submit'),
            ),
            if (_name != null) ...[
              SizedBox(height: 20),
              Text(
                'Hello, $_name!',
                style: TextStyle(fontSize: 20, fontWeight: FontWeight.bold),
              ),
            ],
          ],
        ),
      ),
    );
  }
}

@loic-sharma What do you think about the issue brought up by Harlen #163847 (comment)?

I might be mistaken, but since the Window (and thus the view) is being destroyed in another thread, we might encounter an invalid view ID in this thread by the time that we try to resolve the view. What do you think is appropriate here?

@loic-sharma What do you think about the issue brought up by Harlen #163847 (comment)?

I might be mistaken, but since the Window (and thus the view) is being destroyed in another thread, we might encounter an invalid view ID in this thread by the time that we try to resolve the view. What do you think is appropriate here?

Key events and text input requires multiple asynchronous roundtrips. I suspect synchronizing a view destruction with pending key/text events is hard when we have split UI/platform threads.

@mattkae Can you reproduce this bug when Flutter Windows is in the merged thread mode that Matt Knopp added recently?

@justinmc For the split UI/platform thread mode, can the framework handle this scenario (likely by warning and ignoring the exception) if the Windows embedder produces a better exception?

Key events and text input requires multiple asynchronous roundtrips. I suspect synchronizing a view destruction with pending key/text events is hard when we have split UI/platform threads.

That's what appears to be happening.

@mattkae Can you reproduce this bug when Flutter Windows is in the merged thread mode that Matt Knopp added recently?

It still happens in this cases as far as I can tell.

@mattkae Can you reproduce this bug when Flutter Windows is in the merged thread mode that Matt Knopp added recently?

It still happens in this cases as far as I can tell.

That's unfortunate. Why does that happen? Can we fix it?

I would expect the error to still occur in merged thread mode because the method channels (like TextInput.setClient) are still happening asynchronously, even though the sender and recipient are now on the same thread. It's a longer term refactor for us to move text input to FFI or something in order to take advantage of the single thread.

I would expect the error to still occur in merged thread mode because the method channels (like TextInput.setClient) are still happening asynchronously, even though the sender and recipient are now on the same thread. It's a longer term refactor for us to move text input to FFI or something in order to take advantage of the single thread.

@loic-sharma

@hbatagelo also found the following:

"When we close the window with a focused text field, the focus manager notifies the listeners that the focus has changed, and TextInput.clearClient is called as expected. However, the focus manager notifies the listeners a second time (no idea why), causing the text field to get focus again (TextInput.setClientis called, starting a new transaction). Then the view is destroyed, and focus changes once again, but now TextInput.clearClient is called for the destroyed view, leading to the exception"

Seems like a bug (but perhaps an unrelated/deeper one with the focus manager that we should solve separately)

@mattkae I finally was able to get set up on a Windows machine to try this (per #163847 (comment)), but what is .\lib\services\text_input\test.dart? If I delete that in the command you gave then I get a single visible window and two windows that show up in the task bar but otherwise aren't visible.

I'm hoping to investigate what's going on with the second notification mentioned in #163847 (comment).