Skip to content
Boring Doc
BreakingHigh impactOfficial migration guidesince 2.0.0landed 1.26.0

Added BuildContext parameter to TextEditingController.buildTextSpan

Framework · Official source

A `BuildContext` parameter was added to `TextEditingController.buildTextSpan`.

Original behavior

`TextEditingController.buildTextSpan` is called by `EditableText` on its controller to create the `TextSpan` that it renders. `buildTextSpan` can be overridden in custom classes that extend `TextEditingController`. This allows classes extending `TextEditingController` override `buildTextSpan` to change the style of parts of the text, for example, for rich text editing.

New behavior

With the `BuildContext` available, users can access `InheritedWidgets` inside `buildTextSpan` to retrieve state required to style the text, or otherwise manipulate the created `TextSpan`.

Who is affected
Applications and packages relying on the previous behaviour or signature. Code that uses BuildContext, TextEditingController.buildTextSpan, TextEditingController and related APIs.
Practical impact
Behaviour or API differences that can break builds or change runtime behaviour.
What action should I take?
Follow the official migration guide below, update affected call sites, run `dart fix --apply` where a fix is available, then run your tests.

Before and after (from the official guide)

dart+1−1
Before
1 class MyTextEditingController {
2 @override
3− TextSpan buildTextSpan({TextStyle? style, required bool withComposing}) {
4 /* ... */
5 }
6 }
After
1 class MyTextEditingController {
2 @override
3+ TextSpan buildTextSpan({required BuildContext context, TextStyle? style, required bool withComposing}) {
4 /* ... */
5 }
6 }
Raw before / after
class MyTextEditingController {
  @override
  TextSpan buildTextSpan({TextStyle? style, required bool withComposing}) {
    /* ... */
  }
}
class MyTextEditingController {
  @override
  TextSpan buildTextSpan({required BuildContext context, TextStyle? style, required bool withComposing}) {
    /* ... */
  }
}
Official migration guide (excerpt, © The Flutter Authors, CC BY 3.0)

Overriding TextEditingController.buildTextSpan

Add a required BuildContext context parameter to the signature of the buildTextSpan override.

Code before migration:

class MyTextEditingController {
  @override
  TextSpan buildTextSpan({TextStyle? style, required bool withComposing}) {
    /* ... */
  }
}

Example error message before migration:

'MyTextEditingController.buildTextSpan' ('TextSpan Function({TextStyle? style, required bool withComposing})') isn't a valid override of 'TextEditingController.buildTextSpan' ('TextSpan Function({required BuildContext context, TextStyle? style, required bool withComposing})').

Code after migration:

class MyTextEditingController {
  @override
  TextSpan buildTextSpan({required BuildContext context, TextStyle? style, required bool withComposing}) {
    /* ... */
  }
}

Calling TextEditingController.buildTextSpan

Pass a named parameter 'context' of type BuildContext to the call.

Code before migration:

TextEditingController controller = /* ... */;
TextSpan span = controller.buildTextSpan(withComposing: false);

Error message before migration:

The named parameter 'context' is required, but there's no corresponding argument.
Try adding the required argument.

Code after migration:

BuildContext context = /* ... */;
TextEditingController controller = /* ... */;
TextSpan span = controller.buildTextSpan(context: context, withComposing: false);
Migration assistantAI-generated · grounded in cited sources
AI explanations are not configured
Set AI_PROVIDER (for example to openai-compatible with a local Ollama or LM Studio endpoint) to enable grounded explanations. Everything else on this page works without an AI provider.
Official migration guide·Verified classification (95%)

Listed in the official breaking-changes index (docs.flutter.dev/release/breaking-changes).

An official announcement or migration guide documents an intended behaviour or API change. A verified source change (git diff) shows code changed but does not by itself prove a public API is breaking. AI interpretations are labelled and never used to classify a change.

Source commit
b3045439b7c0
Source last updated
Oct 21, 2026
Last synchronized
Oct 21, 2026
Publication status
published
Publication history
  • Oct 21, 2026, 8:31 PM: new → published (ingestion) — Backed by an official breaking-change/migration guide.
AI explanationAI-generated · grounded in cited sources
AI explanations are not configured
Set AI_PROVIDER (for example to openai-compatible with a local Ollama or LM Studio endpoint) to enable grounded explanations. Everything else on this page works without an AI provider.
Was this useful?