Network tab search box should remain enabled and editable after clearing calls

[BhavyaRaitani]

Steps to reproduce

1. Open Flutter DevTools
2. Run a Flutter app and trigger API calls (click buttons to make HTTP requests)
3. In the Logging tab, type text in the search box (e.g., "http")
4. Network calls are highlighted/filtered matching that search
5. Click "Clear" button to clear all network calls
6. Observe: Search box text remains but is disabled/grayed out

Expected behavior

• After clearing calls, search box should remain enabled (not disabled)
• User can edit the search text (delete, modify, or keep it as-is)
• User can decide: keep search active for next batch of calls OR clear/change it manually
• Search text persists only if user wants it to (user choice, not forced)

Actual behavior

• Search box becomes disabled/read-only after clearing calls
• User cannot modify or clear the search text unless there is a new api call

Why this matters

• Workflow: I clear calls to reduce noise, but want to keep the same search active for the next batch of calls
• OR I want to quickly change search term before new api calls come
• Current behavior blocks this flexibility

Environment

• Flutter version: 3.41.9
• DevTools version: 2.54.2
• Dart version: 3.11.5
• OS: Windows 11

This has also been reproduced on

• Flutter version: 3.35.2
• DevTools version: 2.48.0
• Dart version: 3.9.0
• OS: Windows 11

Video demonstration

See attached video showing:

• Network calls made by clicking "+" button
• Search text typed in search box ("start")
• After clicking "Clear", search box becomes disabled/grayed
• Cannot edit or delete the search text
• When new api call is made, the search box is enabled again and we can edit the text

searchBarDisablesAfterClear.mp4

[BhavyaRaitani]

"Hi team, I did some deep diving into the DevTools source code to see why this happens. I found that this 'disabled-when-empty' logic is explicitly coded into logging_controls.dart, _log_details.dart and network_screen.dart for the search bars.
While I understand this might have been an initial design choice to prevent searching an empty list, it creates a UX inconsistency because the Filter bar right next to it remains enabled regardless of the list size. More importantly, as detailed in my workflow section above, it prevents a developer from pre-configuring a search keyword immediately after clearing the logs to catch a specific incoming event.
I would love to submit a PR to keep the search fields enabled so users can modify or prepare their search terms ahead of incoming logs. Would the team be open to this UX optimization?"

[keertip]

@srawlins