Description

Calling insertChildRenderObject and removeChildRenderObject outside of update or mount in _TableElement should be allowed.

Consider the following minimal reproducible example:

import 'package:flutter/material.dart';

void main() {
  runApp(
    MaterialApp(
      home: Center(
        child: SizedBox(
          width: 100,
          height: 100,
          child: Table(children: [TableRow(children: [W()])]),
        ),
      ),
    ),
  );
}

class W extends StatefulWidget {
  const W({ Key key }) : super(key: key);

  @override
  _State createState() => _State();
}

class _State extends State<W> {
  bool _toggle = true;
  @override
  Widget build(BuildContext context) {
    return _toggle
        ? GestureDetector(onTap: () => setState(() => _toggle = !_toggle), child: Text('Tap me'))
        : SizedBox();
  }
}

Sequence of events after tapping 'Tap me'

1. The onTap callback is called, _State.context is marked dirty.
2. In the next build pass, because GestureDetector was replaced by a widget of a different type, _State.context.updateChild method calls _State.context.deactivateChild.
3. The child's renderObject asks _TableElement to detach it from _TableElement.renderObject, calling _TableElement.removeChildRenderObject.
4. The assertion in _TableElement.removeChildRenderObject fails.

In the above call path only removeChildRenderObject was called on a _TableElement instance, pretty much everything else is happening in the descendant elements which we have no knowledge of in the implementation of Table. So it's probably easier to just remove the asserts than figuring out a way to keep them.

Related PR

_debugWillReattachChildren wasn't brought up in #2961's discussion.

Related Issues

Fixes #31473

Tests

I added the following tests:

• 'Does not crash if a child RenderObject is replaced by another RenderObject of a different type',

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.