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

[SuperEditor] Add test to demonstrate that changing layer builders does not re-layout #2388

Merged
merged 3 commits into from
Dec 20, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
68 changes: 40 additions & 28 deletions super_editor/lib/src/infrastructure/content_layers.dart
Original file line number Diff line number Diff line change
Expand Up @@ -271,34 +271,32 @@ class ContentLayersElement extends RenderObjectElement {
super.markNeedsBuild();
}

/// Builds the underlays and overlays.
void buildLayers() {
contentLayersLog.finer("ContentLayersElement - (re)building layers");

owner!.buildScope(this, () {
final List<Element> underlays = List<Element>.filled(widget.underlays.length, _NullElement.instance);
for (int i = 0; i < underlays.length; i += 1) {
late final Element child;
if (i > _underlays.length - 1) {
child = inflateWidget(widget.underlays[i](this), _UnderlaySlot(i));
} else {
child = super.updateChild(_underlays[i], widget.underlays[i](this), _UnderlaySlot(i))!;
}
underlays[i] = child;
final List<Element> underlays = List<Element>.filled(widget.underlays.length, _NullElement.instance);
for (int i = 0; i < underlays.length; i += 1) {
late final Element child;
if (i > _underlays.length - 1) {
child = inflateWidget(widget.underlays[i](this), _UnderlaySlot(i));
} else {
child = super.updateChild(_underlays[i], widget.underlays[i](this), _UnderlaySlot(i))!;
}
_underlays = underlays;

final List<Element> overlays = List<Element>.filled(widget.overlays.length, _NullElement.instance);
for (int i = 0; i < overlays.length; i += 1) {
late final Element child;
if (i > _overlays.length - 1) {
child = inflateWidget(widget.overlays[i](this), _OverlaySlot(i));
} else {
child = super.updateChild(_overlays[i], widget.overlays[i](this), _OverlaySlot(i))!;
}
overlays[i] = child;
underlays[i] = child;
}
_underlays = underlays;

final List<Element> overlays = List<Element>.filled(widget.overlays.length, _NullElement.instance);
for (int i = 0; i < overlays.length; i += 1) {
late final Element child;
if (i > _overlays.length - 1) {
child = inflateWidget(widget.overlays[i](this), _OverlaySlot(i));
} else {
child = super.updateChild(_overlays[i], widget.overlays[i](this), _OverlaySlot(i))!;
}
_overlays = overlays;
});
overlays[i] = child;
}
_overlays = overlays;
}

@override
Expand Down Expand Up @@ -345,9 +343,19 @@ class ContentLayersElement extends RenderObjectElement {
assert(!debugChildrenHaveDuplicateKeys(widget, [newContent]));

_content = updateChild(_content, newContent, _contentSlot);
// super.update() and updateChild() is where the framework reparents
// forgotten children. Therefore, at this point, the framework is
// done with the concept of forgotten children, so we clear our

if (!renderObject.contentNeedsLayout) {
// Layout has already run. No layout bounds changed. There might be a
// non-layout change that needs to be painted, e.g., change to theme brightness.
// Re-build all layers, which is safe to do because no layout constraints changed.
buildLayers();
}
// Else, dirty content layout will cause this whole widget to re-layout. The
// layers will be re-built during that layout pass.

// super.update() and updateChild() is where the framework reparents
// forgotten children. Therefore, at this point, the framework is
// done with the concept of forgotten children, so we clear our
// local cache of them, too.
_forgottenChildren.clear();
}
Expand Down Expand Up @@ -644,7 +652,11 @@ class RenderContentLayers extends RenderSliver with RenderSliverHelpers {
// content changes.
contentLayersLog.fine("Building layers");
invokeLayoutCallback((constraints) {
_element!.buildLayers();
// Usually, widgets are built during the build phase, but we're building the layers
// during layout phase, so we need to explicitly tell Flutter to build all elements.
_element!.owner!.buildScope(_element!, () {
_element!.buildLayers();
});
});
contentLayersLog.finer("Done building layers");

Expand Down
103 changes: 103 additions & 0 deletions super_editor/test/super_editor/supereditor_theme_switching_test.dart
Original file line number Diff line number Diff line change
@@ -0,0 +1,103 @@
import 'package:flutter/material.dart';
import 'package:flutter_test/flutter_test.dart';
import 'package:flutter_test_runners/flutter_test_runners.dart';
import 'package:super_editor/super_editor.dart';
import 'package:super_editor/super_editor_test.dart';

import 'test_documents.dart';

void main() {
group('SuperEditor > theme switching', () {
testWidgetsOnArbitraryDesktop('switches caret color', (tester) async {
final brightnessNotifier = ValueNotifier<Brightness>(Brightness.light);

await _pumpThemeSwitchingTestApp(tester, brightnessNotifier: brightnessNotifier);

// Place the caret at the beginning of the paragraph.
await tester.placeCaretInParagraph('1', 0);

// Ensure the caret is green, because the theme is light.
expect(_findDesktopCaretColor(tester), Colors.green.shade500);

// Switch the theme to dark.
brightnessNotifier.value = Brightness.dark;
await tester.pumpAndSettle();

// Ensure the caret is red, because the theme is dark.
expect(_findDesktopCaretColor(tester), Colors.red.shade500);
});

testWidgetsOnArbitraryDesktop('switches caret color after typing', (tester) async {
final brightnessNotifier = ValueNotifier<Brightness>(Brightness.light);

await _pumpThemeSwitchingTestApp(tester, brightnessNotifier: brightnessNotifier);

// Place the caret at the beginning of the paragraph.
await tester.placeCaretInParagraph('1', 0);

// Ensure the caret is green, because the theme is light.
expect(_findDesktopCaretColor(tester), Colors.green.shade500);

// Switch the theme to dark.
brightnessNotifier.value = Brightness.dark;
await tester.pumpAndSettle();

// Type a character to trigger a re-layout.
await tester.typeImeText('a');

// Ensure the caret is red, because the theme is dark.
expect(_findDesktopCaretColor(tester), Colors.red.shade500);
});
});
}

/// Pumps a widget tree that rebuilds when the [brightnessNotifier] changes.
///
/// The widget tree contains a [SuperEditor] with a custom caret overlay that
/// changes color based on the brightness of the theme.
Future<void> _pumpThemeSwitchingTestApp(
WidgetTester tester, {
required ValueNotifier<Brightness> brightnessNotifier,
}) async {
final composer = MutableDocumentComposer();
final editor = createDefaultDocumentEditor(
document: singleParagraphDoc(),
composer: composer,
);

await tester.pumpWidget(
MaterialApp(
home: Scaffold(
body: ValueListenableBuilder(
valueListenable: brightnessNotifier,
Copy link
Contributor

Choose a reason for hiding this comment

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

Looking at this widget tree, I'm a little confused about the build behavior.

Your description of the problem is that the overlay builders don't rebuild when the brightness changes.

I'm reading through this tree. I see the ValueListenableBuilder, which rebuilds whenever the brightness changes. When the ValueListenableBuilder rebuilds, it should construct a new SuperEditor instance, which then creates a new DefaultCaretOverlayBuilder. If we're rebuilding the ValueListenableBuilder, and rebuilding the SuperEditor, why isn't the DefaultCaretOverlayBuilder being built?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Because none of the document nodes changed its content. Thus, we are not running another layout phase. We are only repainting the document components, without running a layout phase ContentLayers won't build the overlayers.

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 phrase that statement in terms of the chain of events that I described? What did I get wrong in that series of events? It's not clear what "none of the document nodes changed" has to do with my comment. If we're rebuilding SuperEditor then why isn't SuperEditor running build on its internal ContentLayers? Where are those two builds getting disconnected, such that SuperEditor runs widget build, but ContentLayers doesn't?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This is the sequence of methods being called:

-> INITIAL BUILD
ValueListenableBuilder -> build
SuperEditor -> build
DocumentScaffold -> build
RenderContentLayers -> performLayout
ContentLayersElement -> buildLayers
RenderContentLayers -> performLayout
ContentLayersElement -> buildLayers

-> VALUE NOTIFIER CHANGED 
ValueListenableBuilder -> build
SuperEditor -> build
DocumentScaffold -> build
ContentLayersElement -> update

The critical thing for us is that RenderContentLayers.performLayout is not called. It seems the subtree isn't considered dirty, so the layout does not run again.

Copy link
Contributor

Choose a reason for hiding this comment

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

Do we have any comments in ContentLayersElement.update() that gives a specific reason for us not to rebuild the layers there?

I know that ContentLayers is very hacky, and intentionally avoids various rebuilds of the layers. I'm wondering if this is a place where we should re-run build.

One thing is that when update runs, if we haven't already laid out the content, then we don't have geometry info for the layers. So in that case, we'll need to invalidate layout upon update(). However, if the layout of content hasn't changed, then the previous geometry should still apply, and we should, in theory, be able to re-run build for the layers in the Element, outside of performLayout.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Do we have any comments in ContentLayersElement.update() that gives a specific reason for us not to rebuild the layers there?

We don't. That's the whole implementation:

@override
void update(ContentLayers newWidget) {
  super.update(newWidget);

  final newContent = widget.content(_onContentBuildScheduled);

  assert(widget == newWidget);
  assert(!debugChildrenHaveDuplicateKeys(widget, [newContent]));

  _content = updateChild(_content, newContent, _contentSlot);

  // super.update() and updateChild() is where the framework reparents
  // forgotten children. Therefore, at this point, the framework is
  // done with the concept of forgotten children, so we clear our
  // local cache of them, too.
  _forgottenChildren.clear();
}

So, it seems we are building the content:

final newContent = widget.content(_onContentBuildScheduled);

But since the layers are built during layout, they are not rebuilt.

One thing is that when update runs, if we haven't already laid out the content, then we don't have geometry info for the layers. So in that case, we'll need to invalidate layout upon update()

Calling markNeedsLayout on the RenderObject seems to make it work.

However, if the layout of content hasn't changed, then the previous geometry should still apply, and we should, in theory, be able to re-run build for the layers in the Element, outside of performLayout.

How should we determine that the previous geometry should still apply? Also, I tried calling buildLayers to only rebuild the layers, but then Flutter crashes with the exception:

════════ Exception caught by widgets library ═══════════════════════════════════
The following assertion was thrown building DocumentMouseInteractor(dependencies: [MediaQuery], state: _DocumentMouseInteractorState#59dbd):
'package:flutter/src/widgets/framework.dart': Failed assertion: line 3004 pos 12: '!_debugBuilding': is not true.

The relevant error-causing widget was:
    DocumentMouseInteractor DocumentMouseInteractor:file:///Users/angelosilvestre/dev/super_editor/super_editor/lib/src/default_editor/super_editor.dart:865:16

When the exception was thrown, this was the stack:
#2      BuildOwner.buildScope (package:flutter/src/widgets/framework.dart:3004:12)
framework.dart:3004
#3      ContentLayersElement.buildLayers (package:super_editor/src/infrastructure/content_layers.dart:277:12)
content_layers.dart:277
#4      ContentLayersElement.update (package:super_editor/src/infrastructure/content_layers.dart:358:5)
content_layers.dart:358
#5      Element.updateChild (package:flutter/src/widgets/framework.dart:3949:15)
framework.dart:3949
#6      Element.updateChildren (package:flutter/src/widgets/framework.dart:4098:32)
framework.dart:4098
#7      MultiChildRenderObjectElement.update (package:flutter/src/widgets/framework.dart:7080:17)
framework.dart:7080
#8      Element.updateChild (package:flutter/src/widgets/framework.dart:3949:15)

many more...

Maybe we are calling BuildOwner.buildScope when we are already inside a scope? I tried running the same logic from buildLayers, but without the owner!.buildScope and it seems to work. However, I'm not very familiar with the ContentLayers, so I'm not sure if this could cause any issue.

builder: (context, brightness, child) {
return Theme(
data: ThemeData(
brightness: brightness,
),
child: SuperEditor(
editor: editor,
documentOverlayBuilders: [
// Copy all default overlay builders except the caret overlay builder.
...defaultSuperEditorDocumentOverlayBuilders.where(
(builder) => builder is! DefaultCaretOverlayBuilder,
),
DefaultCaretOverlayBuilder(
caretStyle: CaretStyle(
color: brightness == Brightness.light ? Colors.green : Colors.red,
),
)
],
),
);
},
),
),
),
);
}

Color _findDesktopCaretColor(WidgetTester tester) {
final caret = tester.widget<Container>(find.byKey(DocumentKeys.caret));
return (caret.decoration as BoxDecoration).color!;
}
Loading