fix(web): resolve id: selectors against Flutter's flt-semantics-identifier

[MrEdgarsz]

Proposed changes

I hit this while writing Maestro flows against a Flutter web app: id: selectors just never match anything. The reason turned out to be a bit sneaky. When you set Semantics(identifier: 'login_button') in Flutter, the web engine puts that on a flt-semantics-identifier DOM attribute, but Maestro builds a node's resource-id (what id: actually looks at) from node.id, and on Flutter node.id is an internal handle like flt-semantic-node-7 that gets reassigned between frames. So there's nothing stable to target, and tapOn: { id: ... } just times out.

The change makes maestro-web.js read flt-semantics-identifier first when it's present:

Why

Flutter web is the one place id: is basically unusable. The identifier you set in code doesn't land in the DOM id, it goes into a separate attribute Maestro wasn't looking at. Once it reads that attribute, Semantics(identifier:) behaves the way you'd already expect id: to. That matters more on Flutter than elsewhere, since most text is painted on canvas and labels drift, so a stable id: is really the only reliable selector.

Design notes

I tried to keep this as small and boring as possible:

• The existing node.id || ariaLabel || … chain is untouched. The new attribute is just tried first, and on any page that doesn't have it the expression falls through to exactly the old behaviour.
• flt-semantics-identifier only ever shows up on Flutter web, so nothing changes for any other web app.
• Both web drivers read resource-id out of this script, so they both pick it up from the one change.

Worth flagging: Flutter web only emits its semantics tree once accessibility is enabled, so the attribute isn't in the DOM until then. The demo screen turns it on with ensureSemantics() (web only).

Testing

I added a screen and a flow to the demo app so this is easy to run yourself. lib/semantics_identifier_screen.dart wraps a button in Semantics(identifier: 'login_button'), and .maestro/web_flows/flutter_semantics_identifier.yaml matches and taps it purely by id:, then checks the tap actually fired. With the patch it passes. On main it fails at the id: login_button assertion.

I also checked a plain non-Flutter page still resolves id: (via node.id) and data-testid exactly as before, and :maestro-client:test / :maestro-web:test are green.

Issues fixed

Nothing filed on my end, and I didn't find any in the issues tab that talk about this problem.

[MrEdgarsz]

Revised the e2e after the first CI run. Swapped the served demo-app flow for a self-contained data: URL flow in the date_input.yaml style, so it runs in CI with no server or build. Also fixed a yaml parse slip in the flow name that was failing the suite. The change is now just the maestro-web.js fix plus that one web flow.

Off-topic