Fix failing tests for RawAutocomplete

[victorsanni]

The fixes to RawAutocomplete's options width in the flutter framework (flutter/flutter#143249) introduces a frame delay, so this test requires an extra pump to account for that.

[chrisbobbe]

Welcome, @victorsanni! Are you here because you chose option 2 of the broken-test policy of the Flutter Customer Test Registry?

2. Go through the breaking change process, as documented here: https://github.com/flutter/flutter/blob/master/docs/contributing/Tree-hygiene.md#handling-breaking-changes If you're going to do this, you will need to contact the relevant people responsible for the breaking test(s) (see the relevant .test files), help them fix their code, and update this repository to use the new version of their tests, in addition to the steps described on the wiki. You will also need to land your change in two parts, so that people have time to migrate (a "soft-breaking" change).

I'd like to better understand the rationale for this breaking change. A frame delay doesn't sound ideal; can your bugfixes be done without it? If not, I'd like to see an explanation.

[victorsanni]

Hi @chrisbobbe! Indeed I am here for that reason.

The associated Flutter framework PR fixes the issue where the RawAutocomplete widget goes out of the screen from the right side. But the tradeoff was that unfortunately, the layout of the options view doesn't update on the same frame that the field layout changes.

@gnprice suggested some ideas on how to eliminate the one frame delay, which I implemented in the PR to make the options view relayout when the constraints given to the field change. However, there are still cases where the frame delay remains, which (I think) is causing the failing test.

[chrisbobbe]

@gnprice suggested some ideas on how to eliminate the one frame delay, which I implemented in the PR to make the options view relayout when the constraints given to the field change. However, there are still cases where the frame delay remains, which (I think) is causing the failing test.

It sounds like you found that Greg's ideas had gaps in them 🙂 because they didn't work for some cases. Is there a description of those gaps that you can point Greg to? Then perhaps he'll suggest some new ideas, or else agree and corroborate your claim that the new lag is necessary.

[gnprice]

Thanks @victorsanni for sending this fix! Sorry we didn't follow up again on this sooner. Merged now (and adapted the commit message to our style).

I'm still curious how things turned out in that upstream PR — I recall at one point last month you believed the delay was resolved after all, due to new ideas from LongCat — but I'll catch up there.