Looking up a deactivated widget's ancestor is unsafe

[bhagavati9690]

Can we access your project?

• I give permission for members of the FlutterFlow team to access and test my project for the sole purpose of investigating this issue.

Current Behavior

am experiencing an intermittent console error, Looking up a deactivated widget's ancestor is unsafe, in my FlutterFlow application. This occurs during a common UI interaction flow involving a dialog and a ListView refresh, despite the intended data update and UI refresh working correctly.

Problem Description:

The error manifests when a user interacts with a dialog to filter a list view:

On a parent page, a button is clicked to open a custom dialog.

Inside the dialog, the user selects an option (e.g., a distance filter).

Upon pressing an "Apply" button within the dialog:

    An App State variable (e.g., distance) is updated with the selected value.

    The dialog is dismissed.

On the parent page, in the "On Dialog Close" callback of the "Open Dialog" action:

    The App State variable is again updated with the dialog's returned value (though it's already updated by the dialog's internal action).

    A "Refresh Database Request" action is triggered for the ListView that depends on this App State variable.

While the App State variable is successfully updated and the ListView does refresh to show the correct, filtered data (confirmed via network calls and UI observation), the aforementioned error frequently appears in the browser console. It is intermittent, occurring randomly and not every time the flow is executed.

I have observed that similar logic used elsewhere in the application, where dialogs update App State and trigger list refreshes, does not consistently produce this error.

Error Stack Trace (from console):

js_primitives.dart:28 The following assertion was thrown during a scheduler callback:
js_primitives.dart:28 Looking up a deactivated widget's ancestor is unsafe.
js_primitives.dart:28 At this point the state of the widget's element tree is no longer stable.
js_primitives.dart:28 To safely refer to a widget's ancestor in its dispose() method, save a reference to the ancestor by
js_primitives.dart:28 calling dependOnInheritedWidgetOfExactType() in the widget's didChangeDependencies() method.
js_primitives.dart:28
js_primitives.dart:28 When the exception was thrown, this was the stack:
js_primitives.dart:28 dart-sdk/lib/internal/js_dev_runtime/private/ddc_runtime/errors.dart 288:3 throw
js_primitives.dart:28 packages/flutter/src/widgets/framework.dart 4885:9
js_primitives.dart:28 packages/flutter/src/widgets/framework.dart 4898:14 [_debugCheckStateIsActiveForAncestorLookup]
js_primitives.dart:28 packages/flutter/src/widgets/framework.dart 4919:12 dependOnInheritedWidgetOfExactType
js_primitives.dart:28 packages/clbxmobile/flutter_flow/debug_util.dart 32:19 maybeOf
js_primitives.dart:28 packages/clbxmobile/flutter_flow/flutter_flow_model.dart 96:38 get rootModel
js_primitives.dart:28 packages/clbxmobile/flutter_flow/flutter_flow_model.dart 101:40 get isRouteVisible
js_primitives.dart:28 packages/clbxmobile/flutter_flow/debug_util.dart 202:27
js_primitives.dart:28 packages/flutter/src/scheduler/binding.dart 1397:7 [_invokeFrameCallback]
js_primitives.dart:28 packages/flutter/src/scheduler/binding.dart 1331:11 handleDrawFrame
js_primitives.dart:28 packages/flutter/src/scheduler/binding.dart 1176:5 [_handleDrawFrame]
js_primitives.dart:28 lib/_engine/engine/platform_dispatcher.dart 1408:5 invoke
js_primitives.dart:28 lib/_engine/engine/platform_dispatcher.dart 310:5 invokeOnDrawFrame
js_primitives.dart:28 lib/_engine/engine/initialization.dart 187:36
j

Expected Behavior

Dont't wnt that error that stuck my application at some point

Steps to Reproduce

1.Go to all venue from home page
2.try to change distance

Reproducible from Blank

• The steps to reproduce above start from a blank project.

Bug Report Code (Required)

IT4glfHl8ZN1mMdY0LrULe9amWUvHEwia4c0st5Hd0gdCOPrBuwQZszBXBBpZ+KlaVNcD1H8vHIfw/zevYSWEsInCzSZf7p4+pZ2WhX0e2i6VLqNBcyePnZBEe9NCn6f38KJnxMkOvt1c2Rh2nGAJ+ytfzDDBOu/Zwh9f6PHaOI=

Visual documentation

Environment

- FlutterFlow version: v6.0.21 (released JUNE 17, 2025)
- Platform:(e.g. Web, MacOS Desktop): Web
- Browser name and version:: Chrome 137.0.7151.120
- Operating system and version affected: (desktop): macOS SONOMA 14.6

Additional Information

I attached the video and Action block for referances

[bhagavati9690]

[Alezanello]

This error is a common issue in Flutter (and by extension, FlutterFlow) that occurs when trying to access a widget’s ancestor—typically via context or Provider.of(context)—after the widget has been deactivated or disposed. The specific error message:

"Looking up a deactivated widget's ancestor is unsafe."

means that some code is trying to use a BuildContext that is no longer valid, usually because the widget has been removed from the widget tree (for example, after a dialog is closed).

Why is this happening in your flow?

Here’s a breakdown of the sequence in your app:

1. A dialog opens (e.g., for filtering).
2. The user selects a value and taps "Apply":
   • The dialog updates an App State variable (e.g., FFAppState().distance).
3. The dialog is dismissed (removed from the navigation stack).
4. After the dialog closes:
   • The parent widget updates the same App State variable with the returned value.
   • The parent triggers a refresh of the ListView.

The issue arises because the callback that updates the state or triggers the refresh may run after the dialog’s context has been disposed. Since the widget is no longer part of the active widget tree, trying to access its context leads to this error.

This behavior can be intermittent, depending on timing and how the widget tree updates.

[MartinLockheart]

@Alezanello Quick question on this (if you have a moment), because I've been running into the same thing. Does that mean that we just need to do all of the update/refresh actions and then use the "close dialogue" action at the end of all of that in the callback (and by proxy, avoid closing the dialogue before all of those actions are complete)?

[Alezanello]

Hello!

If you have a custom dialog open and then navigate to another page, Flutter may still attempt to render content from that dialog, which can lead to unexpected behavior.

To avoid this, it's best to dismiss the custom dialog (or bottom sheet) before performing any navigation actions. Just add a Dismiss Dialog or Dismiss Bottom Sheet action right before your Navigate To action.

[bhagavati9690]

@Alezanello
I've implemented the recommended approach: when the 'Apply' or 'Close' button within my custom dialog is pressed, I specifically call the 'Dismiss Custom Dialog' action, also returning the relevant value.

Given this setup, I'm still encountering the 'Looking up a deactivated widget's ancestor is unsafe' error. This suggests my current implementation isn't fully resolving the underlying timing conflict

My key questions are:

Why am I still receiving this error, even though I'm using 'Dismiss Custom Dialog' to manage the dialog's closure? It seems like the issue persists despite my efforts to handle the dialog's lifecycle correctly.
How can I definitively prevent this error from occurring? What specific FlutterFlow adjustments or checks are needed to ensure the widget's BuildContext is always valid when operations are performed?
Is there a way, perhaps through debugging or logs, to identify precisely which ancestor the system is attempting to access when the error is thrown? Understanding the specific BuildContext that has become 'deactivated' would greatly assist in pinpointing the exact problematic line or action.
I'm seeking a robust solution to eliminate this intermittent and frustrating error.

[Alezanello]

This warning usually shows up when something tries to access the widget tree of a dialog after it's already been closed. Here are the main ways that happens:

Common causes:

1. Pending async steps before dismissal
   If there's an async operation (like a backend call, auth, or delay) before the Dismiss Custom Dialog action, the dialog might close, but remaining steps can still try to run — using a context that no longer exists.
2. Extra actions after dismiss
   FlutterFlow doesn't stop executing actions after Dismiss Custom Dialog. If there’s a Set App State, Call Backend, or Show Snackbar tile afterward, those actions can trigger the warning.
3. Active listeners inside the dialog
   Things like ListViews, Streams, or Animations may still fire briefly after the dialog closes and try to interact with the disposed widget tree.

How to fix it

In the Dialog:

• Keep the Dismiss Custom Dialog as the last and only action in the chain.
• If the dialog needs to run a backend call or other async task, place it above the dismiss tile and check “Await completion”.
• Do not add any Set App State, refreshes, or other UI interactions here.

In the Parent Page:

1. Add the Open Custom Dialog action to your button.
   • Enable “Has Return Value” and save it to dialogResult.
2. Use the On Dialog Closed callback to handle updates:
   • Optionally check if dialogResult != null.
   • Set App State or Page State using the returned value.
   • If needed, refresh a query or list.

If your list is already using that App State variable in its filter, the refresh step can be skipped. The query will re-run automatically when the state updates.

If you need to perform something immediately after updating state (like scrolling), add a small delay of around 50ms. That allows Flutter to rebuild safely before the next interaction

Additional checks for safety:

• Make sure Dismiss Custom Dialog is the very last tile in the dialog’s action list.
• Avoid any automatic refresh actions inside the dialog.

Summary pattern to follow:

In the Dialog:

• (Optional) Perform async task (non-blocking disabled)
• Dismiss Custom Dialog (this must be the last action)

In the Parent Page:

• Open Custom Dialog (store result)
• On Dialog Closed:
  • Set App/Page State
  • Optionally refresh list or query

The key rule is: nothing should touch the widget tree after the dialog is dismissed. Keep all logic in the parent page, and this warning will disappear for good.

[MartinLockheart]

That's awesome info, thank you!

…

On Mon, Jun 30, 2025 at 1:52 PM Ale Zanello ***@***.***> wrote: *Alezanello* left a comment (FlutterFlow/flutterflow-issues#6038) <#6038 (comment)> This warning usually shows up when something tries to access the widget tree of a dialog after it's already been closed. Here are the main ways that happens: Common causes: 1. *Pending async steps before dismissal* If there's an async operation (like a backend call, auth, or delay) before the Dismiss Custom Dialog action, the dialog might close, but remaining steps can still try to run — using a context that no longer exists. 2. *Extra actions after dismiss* FlutterFlow doesn't stop executing actions after Dismiss Custom Dialog. If there’s a Set App State, Call Backend, or Show Snackbar tile afterward, those actions can trigger the warning. 3. *Active listeners inside the dialog* Things like ListViews, Streams, or Animations may still fire briefly after the dialog closes and try to interact with the disposed widget tree. How to fix it In the Dialog: - Keep the *Dismiss Custom Dialog* as the *last and only* action in the chain. - If the dialog needs to run a backend call or other async task, place it *above* the dismiss tile and check “Await completion”. - Do not add any Set App State, refreshes, or other UI interactions here. In the Parent Page: 1. Add the Open Custom Dialog action to your button. - Enable “Has Return Value” and save it to dialogResult. 2. Use the *On Dialog Closed* callback to handle updates: - Optionally check if dialogResult != null. - Set App State or Page State using the returned value. - If needed, refresh a query or list. If your list is already using that App State variable in its filter, the refresh step can be skipped. The query will re-run automatically when the state updates. If you need to perform something immediately after updating state (like scrolling), add a small delay of around 50ms. That allows Flutter to rebuild safely before the next interaction Additional checks for safety: - Make sure Dismiss Custom Dialog is the very last tile in the dialog’s action list. - Avoid any automatic refresh actions inside the dialog. Summary pattern to follow: *In the Dialog:* - (Optional) Perform async task (non-blocking disabled) - Dismiss Custom Dialog (this must be the last action) *In the Parent Page:* - Open Custom Dialog (store result) - On Dialog Closed: - Set App/Page State - Optionally refresh list or query The key rule is: nothing should touch the widget tree after the dialog is dismissed. Keep all logic in the parent page, and this warning will disappear for good. — Reply to this email directly, view it on GitHub <#6038 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALI4PYQCXM3UO4LEZ22ADBL3GGPRDAVCNFSM6AAAAAB72FOMZGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAMRQGY3DKNJSGA> . You are receiving this because you commented.Message ID: ***@***.***>

[Alezanello]

Thanks for reporting this! Since this doesn’t appear to be a blocking bug or an issue directly related to FlutterFlow’s functionality, we’ll go ahead and close this ticket for now. If anything changes or you need further assistance, feel free to reopen it or create a new one—we’re here to help!