[hannah-hyj]

demos:
Stage 1 (painter only): https://text-plugin-mvp-demo.web.app/
Stage 2 (annotations): https://text-plugin-annotations-demo.web.app/
Stage 3 (widgets): https://text-plugin-widget-demo.web.app/

Prototype branches link:
Stage 1 (painter only): https://github.com/hannah-hyj/flutter/tree/text-plugin-mvp
Stage 2 (annotations): https://github.com/hannah-hyj/flutter/tree/text-plugin-annotations
Stage 3 (widgets): https://github.com/hannah-hyj/flutter/tree/text-plugin-with-widget

If you want to access demo app code , it's in {branch}/examples/text_plugins

issue: flutter/flutter#65504

#25 was closed in favor of this one

Summary

Proposes a composable text plugin architecture (TextPluginScope, TextPlugin, and TextDelegate) in package:flutter/rendering.dart and package:flutter/widgets.dart.

This enables cross-cutting text inspection, background/foreground decoration painting, pointer gesture handling, and scroll-to-range across standard Text, RichText, and EditableText (TextField) subtrees (RenderParagraph and RenderEditable) without requiring custom text widgets or TextSpan wrappers.

Key Use Cases

• In-page find & highlight (Ctrl+F) across lazy scrollables (ListView.builder) and text fields
• Non-intrusive inline annotations, spellcheck/grammar squiggles, and interactive token tooltips
• Accessibility and localization auditing overlays (e.g., text truncation, contrast, and scaling diagnostics)

Pre-launch Checklist

• I read RFC 000.0001: Taxonomy and followed the file and path naming and metadata standards.
• I read RFC 000.0002: Process and confirmed this proposal meets the threshold for a full RFC.
• I read and agree to the Code of Conduct.
• I signed the CLA.
• I have linked an issue from flutter/flutter with the label design doc.
• All existing and new tests are passing.
• I have enabled "Allow edits from maintainers" on this PR so the bot can automatically assign an RFC number (or I will run dart run bin/assign_rfc_number.dart locally when instructed).

If you need help, consider asking for advice on the #hackers channel on Discord.

[justinmc]

Quick drive by review until I can take a deeper look:

The demo is awesome. Can you share the source code? I think the repo (https://github.com/hannah-hyj/flutter_text_plugin_demo) contains only the compiled assets.

One thing we should be wary of in this design is complexity that increases with the amount of text on the page. Flutter is currently already pretty bad at handling large amounts of text, but we should avoid making that worse if we can.

[Renzo-Olivares]

SelectableRegion has this same problem, we've worked around this in the text case by ordering by topLeft, but this likely is not robust enough for all text use-cases. Would be interested in seeing if this same LCA ordering can be used for SelectableRegion and if there's anything that can be shared here.

[Renzo-Olivares]

I'd argue this may be a good candidate for a first-party plugin since spell check is a default feature we currently provide. That decoration is baked into the InlineSpan itself but it does surface the question about what default capabilities should use the plugin system or just directly modify the InlineSpan for decorations.

[chunhtai]

Do you think this should be in flutter/flutter or flutter/package? that is - is this a OS behavior or design library behavior

[hannah-hyj]

I agree it is a good candidate. On flutter/flutter versus flutter/packages I do not have an answer yet, and I listed it as open.

[Renzo-Olivares]

Good callout, I wonder if we can have a OverrideSelectionStyleTextPlugin or similar that a user can wrap around a subtree to handle this use-case. Probably non-blocking for initial implementation but we should consider it if we do plan to migrate selectableregion to use the plugin. Personally I lean towards that migration since it further decouples selection from text.

[justinmc]

There are probably lots of little details about whether we want to expose certain properties on some of the core classes, etc. but overall I think this looks really good for such an ambitious project. The demo is really great proof of this idea.

For the record I was reviewing the code and example code here: flutter/flutter@master...hannah-hyj:flutter:text-plugin-testing

[justinmc]

I mentioned this elsewhere, but I wonder about the performance of how this is done. Ideally we do this in a way that scales with the amount of text on the page.

[justinmc]

severe traps

I wish we had a clear "text layout" phase, and then we could run a secondary layout after that similar to LayoutBuilder. That way it would be very clear when text metrics are available and not.

This is probably beyond the scope of this RFC though. I think the proposal below is reasonable.

[justinmc]

I wonder what @chunhtai thinks of this.

[chunhtai]

Do you think this should be in flutter/flutter or flutter/package? that is - is this a OS behavior or design library behavior

[chunhtai]

at most one of the did* will be called during a flushLayout? The name didLayoutText feels like will be called whenever the text is laid out accompany a didAddText and didUpdateText. maybe rename it like didRelayoutText

However, do you think we need to tell between didUpdateText and didLayoutText, or can they be a single didUpdate?

[chunhtai]

is TextDelegate a read only interface? we need to make sure that is the case if possible in case people wrote plugin that mutate the provided TextDelegate.

[chunhtai]

better if it can be factory to create TextPlugin instead of an TextPlugin object directly.

[chunhtai]

that way if TextPlugin need to be dispose, it will be the inheritedwidget's job to do it. and less of a footgun for the developer who create it on the flight

[chunhtai]

who gets ownership for this object? if it is mutable the developer will need a statefulWidget to keep a reference to SearchInPagePlugin and pass it into the TextPluginScope.

bascially are you imagine the usage to look like

MyState extends State {
  late SearchInPagePlugin plugin = SearchInPagePlugin();
  
  @override
  void didUpdateWidget(...) {
     plugin.eagerLoadOffscreenText = widget.someFlag;
  }

  @override
  void dispose(...) {
     plugin.dispose();
  }

  @override
  void build(..) {
     return TextPluginScope(
         plugins: {SearchInPagePlugin: plugin}
    
     )
  }
}

or

MyWidget extends StatelessWidget {

  void _createSearchPlugin() {
     return SearchInPagePlugin(eagerLoadOffscreenText: someFlag);
  }

  @override
  void build(..) {
     return TextPluginScope(
         plugins: {SearchInPagePlugin: _createSearchPlugin}
    
     )
  }
}

I can see issue with both though.

if using state, the developer needs to handle its lifecycle and waste of resource if it gets override in the latter plugin scope.

If using factory, we need a way to let TextPluginScope to know when to recreate the plugin even if the factory instance is the same.

[loic-sharma]

Are you allowed to invalidate layout or build widgets during PipelineOwner.schedulePostLayoutCallback? (I suspect the answer should be no, and if possible PipelineOwner.schedulePostLayoutCallback should strictly enforce this with assertions)

[loic-sharma]

I assume the post-layout callback is called after the PipelineOwner has also flushed its children PipelineOwners layout? That might be worth stating since that has implications on what layout information is available to you when the post-layout callback is invoked.

[loic-sharma]

A potential alternative to might be to introduce a RendererBinding.addPostLayoutCallback method (I changed schedule->add to better mirror RendererBinding.addPostFrameCallback).

RendererBinding.drawFrame() would call this after flushing the root pipeline owner's layout. The benefit of this approach is that it would happen once per frame, instead of once per frame for each render tree.

[loic-sharma]

For things like stacked navigation of pages or tabbed content - where widgets are mounted but not visible - will we automatically opt them out of plugins?

[loic-sharma]

If the match is in a multi-line text field but the match is not currently visible, you need to scroll the text field itself to make the match visible - will that work? Is that something the TextDelegate (in this case RenderEditable) is responsible for figuring out?

[loic-sharma]

People might want to heavily customize the search UI. Will we allow that customization? Also I imagine the default search UI depends on Material/Cupertino, will that logic need to live in flutter/packages? What will the API boundary be between the core framework and the design system packages?

[justinmc]

One feature I just realized we should have for ctrl-f: characters with diacritics in the app text should be matched by the character without the diacritic in the search text. This is how Chrome works today, for example: