Move semantic-related bindings to SemanticsBinding

[goderbauer]

Part of #121573.

Moves all the semantics related stuff out of the other bindings into SemanticsBinding where it belongs (see TODO fixed by this change). We added support for generating semantics information before we saw the need for a dedicated SemanticsBinding. That's why semantics related stuff was found in all the other bindings. This change cleans that up.

Furthermore, it also makes the SemanticsBinding the source of truth of whether semantics information should be generated for the entire app. For this, it introduces a new semanticsEnabled getter (with the option to register listeners for when that value changes) and a new ensureSemantics method, which clients can use to turn on semantics globally. Previously, this was all handled by the PipelineOwner. However, in the multi view world we will have multiple PipelineOwners (one to power each view), so a single source of truth to synchronize the semantics of all these PipelineOwners is needed.

[chunhtai]

Suggested change

	/// Called whenever the platform requests an action to be performed on a
	/// Called whenever the platform requests an action to be performed on a

[chunhtai]

This indirection doesn't seem to add too much value.. maybe just leave _handleSemanticsAction public and let RenderingBinding to handle raw args directly?

[goderbauer]

I do believe it is the responsibility of the semantics layer to decode args as it is the one that picks the messageCodec. If we were to decide that we need to change the message codec used, we should do the change in one place here instead of fixing up client code elsewhere.

Furthermore, the SemanticsActionEvent gives us a little more flexibility in the future to extend the information associated with a SemanticsEvent without breaking the method signature. For example, we may want to add the view ID from where the event was originating in the future.

[chunhtai]

Why not just mark this mustCallSuper?

[goderbauer]

My thinking was that this setup guarantees that accessibilityFeatures is called before handleAccessibilityFeaturesChanged is invoked on subclasses. With mustCallSuper you could accidentally call super at the end of your method and operate on outdated data.

[goderbauer]

But we don't do it this way for other handlers on the bindings, so I will change this to your suggestion as well.

[chunhtai]

What is the use case to expose this API?

[goderbauer]

Rephrasing from the PR description:

Clients can use ensureSemantics to turn on semantics globally for the entire app. Previously, this was all handled internally by the PipelineOwner. However, in the multi view world we will have multiple PipelineOwners (one to power each view), so a single source of truth to turn on semantics for of all these PipelineOwners across the entire app is needed.

[chunhtai]

It is weird that we reuse the same interface for handles from two different object. Do you know why we need to add an ensureSemantics to the SemanticsBinding?
or PipelineOwner can do the logic in the construction and put dispose logic to one callback and reuse the SemanticsHandle class directly?

[goderbauer]

Do you know why we need to add an ensureSemantics to the SemanticsBinding?

See answer to previous question.

or PipelineOwner can do the logic in the construction and put dispose logic to one callback and reuse the SemanticsHandle class directly?

Can you elaborate what you mean by this?

This is mostly here for backwards compatibility. PipelineOwner had an ensureSemantics method that is getting some good use, I didn't want to remove it just yet. But like I said in the other comment, we also need something that manages the state of semantics on/off globally outside of individual PipelineOwners.

[goderbauer]

It is weird that we reuse the same interface for handles from two different object.

The objects have the same purpose, though. They are both handles to denote your interest in semantics. One on a global level, the other on a per-PipelineOwner level.

[chunhtai]

Thanks for explanation, yes this make sense.

What i meant to reuse the SemanticsHandle class is to do something like this

  SemanticsHandle ensureSemantics({ VoidCallback? listener }) {
    _outstandingSemanticsHandles += 1;
    if (_outstandingSemanticsHandles == 1) {
      assert(_semanticsOwner == null);
      assert(onSemanticsUpdate != null, 'Attempted to open a semantics handle without an onSemanticsUpdate callback.');
      _semanticsOwner = SemanticsOwner(onSemanticsUpdate: onSemanticsUpdate!);
      onSemanticsOwnerCreated?.call();
    }
    if (listener != null) {
      _owner.semanticsOwner!.addListener(listener!);
    }
    return SemanticsHandle(() {
    if (listener != null) {
      _owner.semanticsOwner!.removeListenr(listener!);
    }
   _didDisposeSemanticsHandle();
});
  }

but you will have to expose the constructor.

[chunhtai]

One more question though, will we have use case that some views enabled semantics but not others? I don't think there is platform that can turn on accessibility for a certain window only.

If that is the case, maybe we should deprecate the pipelineOwner.ensureSemantics, or redirect the call to SemanticsBinding?

[goderbauer]

I see. I don't think I want to make it easy for people to instantiate SemanticsHandle because doing so is more or less meaningless. A handle only has meaning if it was obtained from one of the ensureSemantics methods.

[goderbauer]

One more question though, will we have use case that some views enabled semantics but not others? I don't think there is platform that can turn on accessibility for a certain window only.

I can't think of any, really.

If that is the case, maybe we should deprecate the pipelineOwner.ensureSemantics, or redirect the call to SemanticsBinding?

I am considering this for a future change. The PipelineOwner will get a bigger refactoring soon to make it fit for multi view.

[chunhtai]

sounds good to me

[chunhtai]

LGTM

[chunhtai]

sounds good to me

[auto-submit]

auto label is removed for flutter/flutter, pr: 121289, due to - The status or check suite Google testing has failed. Please fix the issues identified (or deflake) before re-applying this label.