Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Check if MultiChildRenderObjectElement has an associated RO #78854

Merged
merged 8 commits into from Mar 26, 2021

Conversation

xu-baolin
Copy link
Member

Fixes #78159

If we mount a non-RenderObjectElement to MultiChildRenderObjectElement will cause ContainerRenderObjectMixin works abnormal. This is because the MultiChildRenderObjectElement.insertRenderObjectChild depend on the RO to decide where the new RO to insert. If some of the elements's RO is null, the new RO child will insert at the first position by mistake.

This change tries to add a checker for the situation.

@flutter-dashboard flutter-dashboard bot added the framework flutter/packages/flutter repository. See also f: labels. label Mar 23, 2021
@google-cla google-cla bot added the cla: yes label Mar 23, 2021
@xu-baolin xu-baolin requested a review from chunhtai March 23, 2021 10:40
@@ -6194,6 +6212,10 @@ class MultiChildRenderObjectElement extends RenderObjectElement {
super.update(newWidget);
assert(widget == newWidget);
_children = updateChildren(_children, widget.children, forgottenChildren: _forgottenChildren);
assert(() {
_children.forEach(_debugCheckHasAssociatedRenderObject);
Copy link
Member Author

@xu-baolin xu-baolin Mar 23, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we check after updateChildren, some scenarios where GlobalKey are reused will throw more exceptions. See the test cases for details.
If we want to avoid this happens, we need to extend the updateChildren parameter and pass the check function to it. However, if we do this, the modification is very invasive. What is your opinion?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems like that we can override the inflateWidge and make the check instead. I will try it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@chunhtai Hi,
If we make checking after updateChildren like this commit, it will break some tests because retaken the globalKey will re-parent the RO and trigger the new assert first. Also, need to traverse all the children extra.

Copy link
Member Author

@xu-baolin xu-baolin Mar 25, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And we are not easy to override the Element.updateChildren , because it is too complicated.

@chunhtai
Copy link
Contributor

The original issue seems to be an indexedStack specific issue, where it assume the first renderobject corresponds to index 0, second to index 1, ... and so on. We had the similar issue in RenderParagraph, where we tag the child renderobject with the index.

I am not confident whether we should force the same thing to other widget. For example, column widget does not really care about this

@xu-baolin
Copy link
Member Author

@chunhtai Hey
I think this is a common bug of MultiChildRenderObjectElement, for example

import 'package:flutter/material.dart';

void main() {
  runApp(const MyApp());
}
final Key key = GlobalKey(debugLabel: 'problematic');
class MyApp extends StatelessWidget {
  const MyApp({
    Key key,
  }) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      home: Scaffold(
        appBar: AppBar(title: const Text('Oops')),
        body: Center(
          child: Column(
            // index: 0,
            children: [
              // Container(key: const ValueKey<int>(1)),
              // Container(key: const ValueKey<int>(1), child: Container(key: key)),
              // // Container(key: const ValueKey<int>(2),),
              // Container(key: const ValueKey<int>(2), child: Container(key: key)),
              Text('1'),
              Text('11'),
              const AnotherWidget(),
              Text('2'),
              // Container(),
              // Text('1'),
            ],
          ),
        ),
      ),
    );
  }
}

class AnotherWidget extends Widget {
  const AnotherWidget({Key key}) : super(key: key);

  @override
  Element createElement() => _AnotherElement(this);
}

class _AnotherElement extends Element {
  _AnotherElement(AnotherWidget widget) : super(widget);

  @override
  bool get debugDoingBuild => false;

  @override
  void performRebuild() {}
}

@xu-baolin
Copy link
Member Author

Empty widgets will cause the order of ContainerRenderObjectMixin children to be disordered, resulting in misplaced rendering.

Copy link
Contributor

@chunhtai chunhtai left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good, thanks for fixing this

packages/flutter/lib/src/widgets/framework.dart Outdated Show resolved Hide resolved
bool _debugCheckHasAssociatedRenderObject(Element newChild) {
assert(() {
if (newChild.renderObject == null) {
throw FlutterError.fromParts(<DiagnosticsNode>[
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you use the FlutterErrorDetails?

FlutterError.reportError(FlutterErrorDetails(

and also provides an debugCreateor to the error details. Doing this will print out the where the problematic widget is created

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

Copy link
Contributor

@chunhtai chunhtai left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM


@override
void performRebuild() {}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: new line at the end of file

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
framework flutter/packages/flutter repository. See also f: labels.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

We can write a widget which messes up with MultiChild widgets
3 participants