Skip to content

Use tristate checkbox engine changes - #111032

Merged
yaakovschectman merged 9 commits into
flutter:masterfrom
yaakovschectman:tristate_tests
Sep 8, 2022
Merged

yaakovschectman merged 9 commits into
flutter:masterfrom
yaakovschectman:tristate_tests

Conversation

@yaakovschectman

Copy link
Copy Markdown
Contributor

Sends the mixed checkbox state for tristate checkboxes to the engine in order to update semantics properties. Previously the half-checked/mixed/indeterminate state of a tristate checkbox was not read properly by screen readers.

Addresses #110107

Pre-launch Checklist

  • I read the Contributor Guide and followed the process outlined there for submitting PRs.
  • I read the Tree Hygiene wiki page, which explains my responsibilities.
  • I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
  • I signed the CLA.
  • I listed at least one issue that this PR fixes in the description above.
  • I updated/added relevant documentation (doc comments with ///).
  • I added new tests to check the change I am making, or this PR is test-exempt.
  • All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

@yaakovschectman yaakovschectman added the a: accessibility Accessibility, e.g. VoiceOver or TalkBack. (aka a11y) label Sep 6, 2022
@yaakovschectman yaakovschectman self-assigned this Sep 6, 2022
@flutter-dashboard flutter-dashboard Bot added a: tests "flutter test", flutter_test, or one of our tests p: material_ui material_ui package in flutter/packages framework flutter/packages/flutter repository. See also f: labels. labels Sep 6, 2022
@yaakovschectman

Copy link
Copy Markdown
Contributor Author

Need to wait for next engine roll

@yaakovschectman
yaakovschectman force-pushed the tristate_tests branch 2 times, most recently from 1b82960 to 4f74f1b Compare September 6, 2022 20:44
@yaakovschectman
yaakovschectman marked this pull request as ready for review September 6, 2022 21:01

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just curious, when can this be null? If never, should this be non-nullable?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My thought process was to leave it to default to null when the widget has no checked state or is not tristate, like how checked is nullable and is not set when the widget has no check state.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd tweak the comment to clarify the non-null case as that's not readily apparent. Effectively: non-null if this is a checkbox, true if this is a tristate checkbox in the mixed state, false otherwise.

Perhaps something like:

If non-null, indicates that this subtree represents a checkbox or similar widget with a "checked" state. If true, this is a tristate checkbox in the mixed state.

This must be false when [Checkbox.tristate] is false.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this modify SemanticsFlag.isChecked? If no, why not?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, should isChecked modify SemanticsFlag.isCheckStateMixed?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In all cases I can imagine, they should be mutually exclusive when true, so the question is just whether we want to enforce that internally in the SemanticsConfiguration

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The thing is about asserting that exclusivity is that it would create an issue for the tests that ensure all flags are supported, as they work by setting all accessibility flags and making sure they are each reflected in the resulting semantics. If we do make this assertion, those tests would need to change in a manner that I'm not yet sure on how.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed that generally we should be making liberal use of assertions to assert any invariants, especially since they're documented invariants.

Can you point to tests that would be broken by this? Could be it's the tests that need updating now that we're modelling new state.

@guidezpl
guidezpl removed their request for review September 7, 2022 15:34

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed that generally we should be making liberal use of assertions to assert any invariants, especially since they're documented invariants.

Can you point to tests that would be broken by this? Could be it's the tests that need updating now that we're modelling new state.

@yaakovschectman

Copy link
Copy Markdown
Contributor Author

@cbracken https://github.com/flutter/flutter/blob/394f762c0683491a1807158aa817bd5088697919/packages/flutter/test/widgets/custom_painter_test.dart#L417 and https://github.com/flutter/flutter/blob/394f762c0683491a1807158aa817bd5088697919/packages/flutter/test/widgets/semantics_test.dart#L552 would break with this, as they test by expecting a semantics node with all possible flags set. If two flags assert mutual exclusivity, we cannot possibly create a semantics node that matches that expectation. One option that may coexist with the assertions is to manually remove the mixed flag from the expected semantics to avoid the clash.

@cbracken

cbracken commented Sep 7, 2022

Copy link
Copy Markdown
Member

Sounds like the test needs to be updated since all flags true is no longer a valid state.

@yaakovschectman

Copy link
Copy Markdown
Contributor Author

@cbracken The latest commit addresses this, please take a look.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make the assert a precondition check at the top of the setter to prevent it from getting into a bad state if the user violates an invariant.

@cbracken cbracken left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM stamp from a Japanese personal seal

key: const Key('a'),
container: true,
explicitChildNodes: true,
// flags

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this comment necessary?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you referring to //flags? This was already present in the earlier definitions in this test function, so it was copied to the modified instance created here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

a: accessibility Accessibility, e.g. VoiceOver or TalkBack. (aka a11y) a: tests "flutter test", flutter_test, or one of our tests framework flutter/packages/flutter repository. See also f: labels. p: material_ui material_ui package in flutter/packages

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants