Description

When a TabBarView is nested in a page of another TabBarView, there will be particular scenarios that will throw an exception.

To reproduce this issue, two conditions must be true:

1. Tap on a tab that is adjacent to a tab containing a nested TabBarView
2. The nested tab has to be in between the initial tab and the tab that was tapped on
   (ie. current index = 0, tap on tab at index 3 when tab at index 2 has nested TabBarView)

This happens when the framework tries to build _PagePosition, then dispose of it before applyViewportDimension has the chance to be called to set pixels to a non-null value based on the size of the viewport. This fix adds a flag to determine if applyViewportDimension is invoked before dispose. If it hasn't been, then dispose will set pixels to an arbitrary value before attempting to dispose of it.

First exception: This is due to the introduction of #29188, which happens because the initial swap that is necessary for warping causes the nested page that is swapped but not shown to be disposed of before applyViewportDimension to be called.

Second exception: This one is caused by the animation of the page during warp. The last frame does not build before the second setState is called to swap the children back to their original positions, causing the nested page to be built and disposed of before applyViewportDimension can be called.

TODO:

• Add an issue to track adding a test to ensure that the warp animation for TabBarView builds its last frame before setState is called to re-swap the children back to their original locations. ScrollPosition.animateTo should build last frame before resolving animation #32054
• Track the potential need for a more robust swapping mechanism that doesn't cause pages that are not shown to be built and immediately disposed of. Tab _warpToCurrentIndex causing pages to build and dispose immediately #32056

Related Issues

Fixes #18756

Tests

I added the following tests:

• A regression test to ensure that the exception does throw when a tab adjacent to nested tab is selected. It tests for the first exception case mentioned above. A separate issue will be created to track writing a test for the second exception case.

Checklist

Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I signed the CLA.
• I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
• I updated/added relevant documentation (doc comments with ///).
• All existing and new tests are passing.
• The analyzer (flutter analyze --flutter-repo) does not report any problems on my PR.
• I am willing to follow-up on review comments in a timely manner.

Breaking Change

Does your PR require Flutter developers to manually update their apps to accommodate your change?

• Yes, this is a breaking change (Please read Handling breaking changes). Replace this with a link to the e-mail where you asked for input on this proposed change.
• No, this is not a breaking change.