[DevTools] Update inspected element on component filter changes

[eps1lon]

Summary

We used to only update the inspected element when selected host element changes. This is fine when Components and the browser's Elements panel are alternate. With the inspected element pane you can now have the inspected element and browsers Elements panel side-by-side.

Now we update the inspected element when the filter changes. This is mostly interestiny when the filter becomes less restrictive i.e. we can inspect an element closer to the selected host element. When the filter becomes more restrictive, the store was already selecting the nearest parent.

The new behavior may be disorienting if you're in the Components panel so we could restrict the behavior to apply only when you're changing filter from within the inspected elements pane within the browsers Elements panel.

CleanShot.2026-01-22.at.14.54.22.mp4

How did you test this change?

• Manually verified in Chrome

[hoxyq]

Now thinking a bit more about it, I am not quite sure about this change.

I believe the main use case for filters is to hide a bunch of unnecessary things from the tree, but this also has side effects on selecting the lowest React node that owns the corresponding DOM element.

We don't keep filtered-out nodes in a store, right? I thought maybe we could fork selectNode(...) logic

[eps1lon]

but this also has side effects on selecting the lowest React node that owns the corresponding DOM element.

What side-effects? The intention here was to select a lower element if you don't filter host components.

We don't keep filtered-out nodes in a store, right?

yes. Could you explain why that is a problem here?

[hoxyq]

What side-effects? The intention here was to select a lower element if you don't filter host components.

When selecting React element that owns some DOM element, we will select lowest unfiltered, not just the lowest.

Although from user perspective, the filters feature could only be applied to the actual React tree that you see on Components panel, the current state is a bit unexpected / confusing to me, but this is subjective.

yes. Could you explain why that is a problem here?

Maybe we should keep filtered nodes in a store, I don't know. Maybe these filters should only apply to the visual representation of the tree on the Components panel, and if you use this React pane on Elements panel, it should always use the full tree representation.

[eps1lon]

When selecting React element that owns some DOM element, we will select lowest unfiltered, not just the lowest.

That's what I meant to convey with "lowest". If it would select the lowest, it would just select the element itself.

Maybe we should keep filtered nodes in a store, I don't know. Maybe these filters should only apply to the visual representation of the tree on the Components panel, and if you use this React pane on Elements panel, it should always use the full tree representation.

That's a pretty big refactor. I don't see how this PR contradicts that. I consider this mostly a UX bug fix since we didn't update the view when we update the filter. Right now you have to click back and forth which seems worse than automatically updating the view.

[hoxyq]

I consider this mostly a UX bug fix since we didn't update the view when we update the filter.

It totally makes sense for the Element pane case, but I think at the same time it adds an unpredictable behaviour on Components panel.

I can be wrong, but I would expect the following scenario to be possible:

1. You select element X that renders div on Components panel
2. (Maybe optional) You navigate to Elements panel and you see div selected, maybe you click on it again
3. You navigate back to Components panel, change filters and remove DOM elements exclusion rule
4. You see that the div element was selected automatically on the Components panel

I am not blocking this change, I feel like it perfectly makes sense for the case with pane on Elements panel. Maybe we should rethink the filters as a feature in a future.