Reset Network panel filter for requests linked from console

VERIFIED FIXED in Firefox 43

Status

()

Firefox
Developer Tools: Console
VERIFIED FIXED
2 years ago
2 years ago

People

(Reporter: sebo, Assigned: past)

Tracking

Trunk
Firefox 43
Points:
---

Firefox Tracking Flags

(firefox43 fixed)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

2 years ago
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

2 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)

Updated

2 years ago
Duplicate of this bug: 1204484
(Assignee)

Comment 3

2 years ago
I have a fix for this.
Assignee: nobody → past
Status: NEW → ASSIGNED
(Assignee)

Comment 4

2 years ago
Created attachment 8660668 [details] [diff] [review]
Reset the network panel filter for requests linked from the console (bug 1204481).
(Reporter)

Comment 5

2 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

2 years ago
Created attachment 8660870 [details] [diff] [review]
Patch v2

Now with a test.
Attachment #8660668 - Attachment is obsolete: true
(Assignee)

Updated

2 years ago
Attachment #8660870 - Flags: review?(vporof)
(Assignee)

Comment 7

2 years ago
Created attachment 8661080 [details] [diff] [review]
Patch v3

(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

2 years ago
Attachment #8661080 - Flags: review?(vporof)
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

2 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.

Comment 10

2 years ago
https://hg.mozilla.org/integration/fx-team/rev/3c30e2768d9d
https://hg.mozilla.org/mozilla-central/rev/3c30e2768d9d
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
status-firefox43: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 43
(Reporter)

Comment 12

2 years ago
Works fine for me now. Thank you very much, Panos!

Sebastian
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.