I'm hoping we can just remove these (at least the timer).

Per @chunhtai (if I recall correctly) this is for cases like navigating to a new route with an "autofocus: true" text field. But I think when that happens, the accessibility bridge would have already received the new semantics tree, especially with the current implementation where autofocus is scheduled in a post frame callback and semantics updates are sent synchronously to the accessibility bridge on iOS.

@chunhtai do you think this can be removed?

Also, if we're worried about the timing with the semantics tree update, shouldn't accessibility bridge be the one that calls enableActiveViewAccessbility when it's ready, instead of the text input plugin tries to coordinate with the accessibility bridge?

The current implementation was five years ago bf551a3.

Where this changed was introduced 4 years ago d2dacb3

I am not sure if this is still needed either though.

if we're worried about the timing with the semantics tree update, shouldn't accessibility bridge be the one that calls enableActiveViewAccessbility.

This is only an issue due to iOS internal implementation that it reuses UItextinput for text editing and a11y tree. From the framework perspective, there is nothing wrong that autofocus the textfield and then sends a11y tree update. The keyboard focus and a11y focus are separated concepts in the first place.

Is removing this delay necessary for autofill to work?

Is removing this delay necessary for autofill to work?

I would think not (it's more of a drive-by comment).

From the framework perspective, there is nothing wrong that autofocus the textfield and then sends a11y tree update. The keyboard focus and a11y focus are separated concepts in the first place.

Yeah the framework doesn't have to know about the details of what UIKit / the text input plugin does, but the iOS accessibility bridge is specialized for the iOS implementation, and to me it seems to be the perfect place to determining when to switch between an a11y node and the "real" input field (instead of using a timer in TextInputPlugin). But again I digress.

IIRC the PR moves the switch code from show/hide to setInputClient/clearInputClient, so the timing is a bit different and the app may call show/hide themselves to dismiss / reveal the virtual keyboard. Do you happen to know if that will break anything, or are there things we should test to make sure there's no regression.

the iOS accessibility bridge is specialized for the iOS implementation, and to me it seems to be the perfect place to determining when to switch between an a11y node and the "real" input field (instead of using a timer in TextInputPlugin). But again I digress.

Oh I misread the original question, yeah moving this to ios a11ybridge is fine. It just feels a bit weird that a11y needs to listen to textinputplugin activation and then set the attribute on textinputplugin, but I get it makes a bit more sense to structure the code this way

PR moves the switch code from show/hide to setInputClient/clearInputClient, so the timing is a bit different and the app may call show/hide themselves to dismiss / reveal the virtual keyboard. Do you happen to know if that will break anything, or are there things we should test to make sure there's no regression.

I think this is probably fine. to do a manual test just create a push a new route with autofocus textfield in voice over and see if you will see weird focus behavior

Sounds good I'll give that a try.

(trying the implementation out now).

I tried out the patch and the behavior seems to be exactly the same in my test app:

class _MyHomePageState extends State<MyHomePage> {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
        body: Center(
      child: TextButton(
          onPressed: () {
            Navigator.of(context).push(MaterialPageRoute(builder: (context) {
              return Scaffold(
                //appBar: AppBar(title: const Text('My Page')),
                body: Column(
                  children: [
                    TextButton(
                      child: const Text('POP'),
                      onPressed: () {
                        Navigator.pop(context);
                      },
                    ),
                    TextField(
                      autofocus: true,
                    )
                  ],
                ),
              );
            }));
          },
          child: Text('123')),
    ));
  }
}

The only weirdness I observed: when I press the "123" button and wait for the route transition to finish, the accessibility focus indicator (the rectangle with black borders) would sometimes show over an empty area with no interactive UI elements and announce "one hundred and twenty three". I'm seeing that with and without this patch so I guess that's not related.