[CP-stable]Make _layoutBoundary a boolean 2

[flutteractionsbot]

This pull request is created by automatic cherry pick workflow
Please fill in the form below, and a flutter domain expert will evaluate this cherry pick request.

Issue Link:

What is the link to the issue this cherry-pick is addressing?

#168936.

Changelog Description:

Explain this cherry pick in one line that is accessible to most Flutter developers. See best practices for examples

Fixes a "Null check operator used on a null value" crash when a scroll view contains a LayoutBuilder.

Impact Description:

What is the impact (ex. visual jank on Samsung phones, app crash, cannot ship an iOS app)? Does it impact development (ex. flutter doctor crashes when Android Studio is installed), or the shipping production app (the app crashes on launch)

The app may crash if there a LayoutBuilder child inside of a RenderSliverMultiBoxAdaptor (which SliverList uses), and that child suddenly becomes offstage and kept-alive.

One example is when you have a TextField inside of a LayoutBuilder which is part of a SliverList. The app crashes ("Null check operator used on a null value") even in release mode when the user drags so that the text field becomes offscreen. All 3 are popular widgets so I think this combination will not be that uncommon.

Workaround:

Is there a workaround for this issue?

There's no known workaround for this issue. You can increase the cache extent to prevent the child from becoming kept-alive but this is not really feasible for long / infinite list as it will go OOM fast.

Risk:

What is the risk level of this cherry-pick?

• Low
• Medium
• High

This should be a relatively safe fix.

Despite changing an important flag in RenderObject from RenderObject? to bool?, there's only one change in behavior:

in RenderObject.dropChild: https://github.com/flutter/flutter/pull/169958/files#diff-4c298197a8aa7831a26eece096c8b8b07773ba1f5376d848ea4ef2924b606e9fL2052
which originally set the flag to null for the entire subtree until a new relayout boundary is reached, now it only sets the flag to null for the root of the subtree.
In release mode, the only place the framework cares about whether the flag is null is here (everywhere else null just means false), and that won't actually introduce any correctness issues because if the node originally enters the if block in line 2343 it will still enter the if block after the patch.

Also, the fix was merged a couple weeks ago and I haven't seen bug reports associated with the fix yet.

Test Coverage:

Are you confident that your fix is well-tested by automated tests?

• Yes
• No

Validation Steps:

What are the steps to validate that this fix works?

follow the repro steps in #168936, or
run the test (already checked in in master)

testWidgets('LayoutBuilder does not crash when it becomes kept-alive', (
    WidgetTester tester,
  ) async {
    final FocusNode focusNode = FocusNode();
    final TextEditingController controller = TextEditingController();
    addTearDown(focusNode.dispose);
    addTearDown(controller.dispose);
    final Widget layoutBuilderWithParent = SizedBox(
      key: GlobalKey(),
      child: LayoutBuilder(
        builder: (BuildContext _, BoxConstraints _) {
          // The text field keeps the widget alive in the SliverList.
          return EditableText(
            focusNode: focusNode,
            backgroundCursorColor: const Color(0xFFFFFFFF),
            cursorColor: const Color(0xFFFFFFFF),
            style: const TextStyle(),
            controller: controller,
          );
        },
      ),
    );

    await tester.pumpWidget(
      Directionality(
        textDirection: TextDirection.ltr,
        child: CustomScrollView(
          slivers: <Widget>[
            SliverList.list(
              addRepaintBoundaries: false,
              addSemanticIndexes: false,
              children: <Widget>[const SizedBox(height: 60), layoutBuilderWithParent],
            ),
          ],
        ),
      ),
    );
    focusNode.requestFocus();
    await tester.pumpWidget(
      Directionality(
        textDirection: TextDirection.ltr,
        child: CustomScrollView(
          slivers: <Widget>[
            SliverList.list(
              addRepaintBoundaries: false,
              addSemanticIndexes: false,
              children: <Widget>[const SizedBox(height: 6000), layoutBuilderWithParent],
            ),
          ],
        ),
      ),
    );
  });

[flutteractionsbot]

@LongCatIsLooong please fill out the PR description above, afterwards the release team will review this request.

[flutter-dashboard]

This pull request was opened from and to a release candidate branch. This should only be done as part of the official Flutter release process. If you are attempting to make a regular contribution to the Flutter project, please close this PR and follow the instructions at Tree Hygiene for detailed instructions on contributing to Flutter.

Reviewers: Use caution before merging pull requests to release branches. Ensure the proper procedure has been followed.

[matanlurey]

@LongCatIsLooong You will need to push a blank commit to have the tests re-run, and assuming they pass, we can merge.

It will not make it in this weeks' release.

[LongCatIsLooong]

@LongCatIsLooong You will need to push a blank commit to have the tests re-run, and assuming they pass, we can merge.

It will not make it in this weeks' release.

This is automatically generated by flutteractionsbot so I don't know how to push a new commit. Does it work if I manually rerun using the github UI, or close this PR and add the CP label to the fix PR again so the bot creates a new PR?

[matanlurey]

If you want to rerun 31 tasks manually, sure.

Otherwise you should have permissions to push commits to this branch as a maintainer (similar to how you could for another person's PR). If you aren't sure how I'd ask someone on your team, but you would checkout the branch and commit to it.

[OliverNarramore]

Are there any updates on this? Please and thank you

[ivanchaukn]

@matanlurey Looks like all checks are passed. Why can't we approve it? It's a blocker for my app and we need it on the stable channel

[blastervla]

+1... I honestly don't understand how this is not a priority and a bug fix is released immediately. This has been broken for quite a bit now, and it is not a minor issue. It causes widgets to directly not render at all

[camsim99]

LGTM