Allow to search within raw network response
Categories
(DevTools :: Netmonitor, enhancement, P3)
Tracking
(Not tracked)
People
(Reporter: sebo, Assigned: colin.cazabet)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
While the Netmonitor allows to search within all request data, there is currently no way to search only within a specific response text.
There should be an option within the Response view to search within the response text.
A solution to this would be a search bar that opens within the Response view when pressing Ctrl
+F
and/or via an option within the context menu.
Sebastian
Comment 1•3 years ago
|
||
Thank you for the report Sebastian.
Do you think Bug 1553201 is a dup?
Reporter | ||
Comment 2•3 years ago
|
||
I see bug 1553201 to introduce a UI for searching within the formatted JSON response, while this bug is explicitly for a UI for searching within the raw response.
The UI for searching may end up to be the same, e.g. a search bar as described above, though I imagine this one here to highlight the value within the raw response while in the other bug we may end up filtering the JSON tree view.
Sebastian
Comment 3•3 years ago
|
||
Ok, thank you.
Also note, that it's possible to search all (raw) response bodies using the Search side panel. The existing search logic should be considered when working on this feature.
Honza
Comment 4•3 years ago
|
||
Assignee | ||
Comment 5•3 years ago
|
||
Hello,
I'm interested to work on this, if I understand well, we need to:
- add a searchbar on the response view when ctrl+f is pressed (or a button in the context menu)
- highlight the elements that match in the raw response (if raw is not checked in the response view, what should we do ? should we force it ?)
- go to the next match when enter is pressed
- hide the searchbar on escape
Thank you
Colin
Comment 6•3 years ago
|
||
Hey Colin,
yes, your list looks great, thanks for helping with this!
add a searchbar on the response view when ctrl+f is pressed (or a button in the context menu)
There is already a search bar in the Debuger panel (opens on Ctrl+F), see the attached screenshot. We should use the same thing, so the UI/UX is consistent across DevTools UI. This should also help us to avoid dupping a lot of code.
Is there anything blocking us from re-using this in the Network panel?
I think that both, Ctrl+F and Context menu should be supported to open the search bar.
We should also move the SearchBar component to devtools/client/shared/components/search
directory.
highlight the elements that match in the raw response
go to the next match when enter is pressed
hide the searchbar on escape
Yes, look at the Debugger implementation, the UX should be the same (CodeMirror might do some of that I guess).
if raw is not checked in the response view, what should we do ? should we force it ?
Yes, forcing to raw (and keeping raw even after the search bar is closed)
Honza
Assignee | ||
Comment 8•3 years ago
|
||
Hello jan,
thank you for all the details !
I think we can indeed reuse this component on the network panel, I'll ask here if I encounter some problems.
Yes can you please assign it to me ?
Thank you,
Colin
Comment 9•3 years ago
|
||
Perfect, assigned to you.
Assignee | ||
Comment 10•2 years ago
|
||
Comment 11•2 years ago
|
||
Sorry Colin, I missed you were working on that and I landed something that looks similar in Bug 1779164
I'm only deferring the search handling to CodeMirror, so it doesn't look the same as in the debugger though.
Honza, should we close this bug or do we want to use it to have something more similar to the debugger UI ?
Comment hidden (off-topic) |
Comment 13•2 years ago
|
||
Go home Release mgmt bot, you're drunk!
re-setting Colin as assignee since we submitted a patch yesterday
Comment 14•2 years ago
|
||
Sorry, there was a problem with the detection of inactive users. I'm reverting the change.
Comment hidden (off-topic) |
Comment hidden (off-topic) |
Comment 17•2 years ago
|
||
The bug assignee is inactive on Bugzilla, so the assignee is being reset.
Updated•2 years ago
|
Comment 18•2 years ago
|
||
The bug assignee is inactive on Bugzilla, so the assignee is being reset.
Updated•1 years ago
|
Comment 19•1 years ago
|
||
Honza or Bomsy, Can you check Colin's question at https://phabricator.services.mozilla.com/D152597#5945360 ? as well as comment 11 from Nicolas. Is this bug still needed?
Comment 20•1 years ago
|
||
Had a chat offline with Honza, and we think the fix by Nicholas from Bug 1779164 works nicely for now. We just need a light simple search now.
Thanks for your time spent on this Colin.
I'll close this now.
Description
•