Closed
Bug 1204481
Opened 9 years ago
Closed 9 years ago
Reset Network panel filter for requests linked from console
Categories
(DevTools :: Console, defect)
DevTools
Console
Tracking
(firefox43 fixed)
VERIFIED
FIXED
Firefox 43
Tracking | Status | |
---|---|---|
firefox43 | --- | fixed |
People
(Reporter: sebo, Assigned: past)
References
Details
Attachments
(1 file, 2 obsolete files)
(deleted),
patch
|
vporof
:
review+
|
Details | Diff | Splinter Review |
When somebody clicks on a network request within the Console panel, the display switches to the Network panel since bug 861335 to show the request details there.
Though if the Network panel has a filter set and the clicked request does not match the filter, the request details are not displayed.
Example:
You have 'JS' set as filter within the Network panel. Within the Console panel you click on a CSS resource.
=> The display switches to the Network panel, though in there nothing happens.
Sebastian
Reporter | ||
Comment 1•9 years ago
|
||
Btw. the filter may just be reset in case the resource doesn't match the currently set filter.
Also, there may be a notification when the filter is reset.
Sebastian
Assignee | ||
Comment 3•9 years ago
|
||
I have a fix for this.
Assignee: nobody → past
Status: NEW → ASSIGNED
Assignee | ||
Comment 4•9 years ago
|
||
Reporter | ||
Comment 5•9 years ago
|
||
So it looks like you decided to always reset the filter. What speaks against the solution in comment 1?
Sebastian
Assignee | ||
Comment 6•9 years ago
|
||
Now with a test.
Attachment #8660668 -
Attachment is obsolete: true
Assignee | ||
Updated•9 years ago
|
Attachment #8660870 -
Flags: review?(vporof)
Assignee | ||
Comment 7•9 years ago
|
||
(In reply to Sebastian Zartner [:sebo] from comment #5)
> So it looks like you decided to always reset the filter. What speaks against
> the solution in comment 1?
Sorry, I didn't see your comment yesterday. That behavior was already there from the previous iterations of the patch, but I agree that only resetting it when absolutely necessary is preferable. Here is an updated version that does just that.
Attachment #8660870 -
Attachment is obsolete: true
Attachment #8660870 -
Flags: review?(vporof)
Assignee | ||
Updated•9 years ago
|
Attachment #8661080 -
Flags: review?(vporof)
Comment 8•9 years ago
|
||
Comment on attachment 8661080 [details] [diff] [review]
Patch v3
Review of attachment 8661080 [details] [diff] [review]:
-----------------------------------------------------------------
::: browser/devtools/netmonitor/netmonitor-controller.js
@@ +339,5 @@
> let predicate = i => i.value === requestId;
> request = NetMonitorView.RequestsMenu.getItemForPredicate(predicate);
> + if (!request) {
> + // Reset filters so that the request is visible.
> + NetMonitorView.RequestsMenu.filterOn("all");
Why not just always do this? Just curious.
Attachment #8661080 -
Flags: review?(vporof) → review+
Assignee | ||
Comment 9•9 years ago
|
||
(In reply to Victor Porof [:vporof][:vp] from comment #8)
> Why not just always do this? Just curious.
Having to continuously adjust the netmonitor filter back to, say JS, after going to the console and back, will surely start taking its toll on someone only interested in JS files.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 43
Reporter | ||
Comment 12•9 years ago
|
||
Works fine for me now. Thank you very much, Panos!
Sebastian
Status: RESOLVED → VERIFIED
Updated•6 years ago
|
Product: Firefox → DevTools
You need to log in
before you can comment on or make changes to this bug.
Description
•