Filter Network requests by column values in Developer Tools

VERIFIED FIXED in Firefox 55

Status

()

Firefox
Developer Tools: Netmonitor
P3
major
VERIFIED FIXED
4 years ago
a year ago

People

(Reporter: Žilvinas, Assigned: ntim, Mentored)

Tracking

(Blocks: 1 bug, {dev-doc-complete})

31 Branch
Firefox 55
dev-doc-complete
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox55 verified)

Details

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.20 Safari/537.36

Steps to reproduce:

I opened Firefox Dev Tools. Clicked on Network tab in Dev Tools. 


Actual results:

I only was able to filter out them by content type (HTML, CSS, XHR and etc.)


Expected results:

I should have been able to filter by the values in the columns such as Method, File, Domain, Size and etc.
(Reporter)

Updated

4 years ago
Severity: normal → major
Component: Untriaged → Developer Tools: Netmonitor

Comment 1

4 years ago
might be same as bug 1062851
(Reporter)

Comment 2

4 years ago
No, this is more about not having a feature to filter by column value, I can see columns properly.

Comment 3

3 years ago
Appears related to bug 923192

Updated

3 years ago
Assignee: nobody → sky
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

3 years ago
Mentor: ejpbruel
(Assignee)

Updated

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

Updated

2 years ago
Assignee: sky → nobody
Keywords: dev-doc-needed
Priority: -- → P3
(Assignee)

Updated

a year ago
Mentor: ejpbruel → odvarko
For what it's worth, the Chrome DevTools allow to search by specific options via search tags. E.g. to search for the HTTP status you enter "status-code:" and then the number.

Sebastian
Depends on: 923192
OS: Mac OS X → Unspecified
Hardware: x86 → Unspecified
See Also: → bug 1334408
With bug 862855 being implemented the UX for searching for a hidden info should be considered.
E.g. when the 'Method' column is hidden but you search for the method, the filtering might be confusing.

One way to make this obvious would be to automatically open the side panel and highlight the related information there and allow to toggle through the matches by pressing Enter similar to how it's proposed for responses in bug 1334408.

This might be done in a separate bug if needed.

Sebastian
See Also: → bug 862855
(Assignee)

Comment 7

a year ago
(In reply to Sebastian Zartner [:sebo] from comment #6)
> With bug 862855 being implemented the UX for searching for a hidden info
> should be considered.
> E.g. when the 'Method' column is hidden but you search for the method, the
> filtering might be confusing.

I don't see how it's confusing if you explicitly write: `method:get` in the search input (this is the UI I'm planning to implement btw, to be consistent with chrome).
Yeah, you're right. It should be clear to the users when they explicitly type 'method:get' that this filters the requests the HTTP method.

Two more points:
I believe the autocompletion should be available for both, the filter and the value, like it's done in Chrome.
And do you plan to add additional filters for information that is currently not visible within the columns in this bug, like e.g. the scheme, or special ones like 'is:from-cache'? Or will that be handled in bug 859047 or a another bug?

Sebastian
(Assignee)

Comment 9

a year ago
(In reply to Sebastian Zartner [:sebo] from comment #8)
> Yeah, you're right. It should be clear to the users when they explicitly
> type 'method:get' that this filters the requests the HTTP method.
> 
> Two more points:
> I believe the autocompletion should be available for both, the filter and
> the value, like it's done in Chrome.
I don't plan to implement autocompletion initially. This can happen in a different bug.

> And do you plan to add additional filters for information that is currently
> not visible within the columns in this bug, like e.g. the scheme, or special
> ones like 'is:from-cache'? Or will that be handled in bug 859047 or a
> another bug?

I don't support everything from this list:

https://github.com/ChromeDevTools/devtools-frontend/blob/16e3b8c8a824315ac2b4c07ca4e4a01fc18f2cea/front_end/network/NetworkLogView.js#L1764

Here are the unsupported fields:
- cookie-related fields
- has-response-header
- mixed-content
- priority
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)
(Assignee)

Updated

a year ago
Duplicate of this bug: 923192
Blocks: 1354504
(In reply to Tim Nguyen :ntim from comment #9)
> (In reply to Sebastian Zartner [:sebo] from comment #8)
> > Yeah, you're right. It should be clear to the users when they explicitly
> > type 'method:get' that this filters the requests the HTTP method.
> > 
> > Two more points:
> > I believe the autocompletion should be available for both, the filter and
> > the value, like it's done in Chrome.
> I don't plan to implement autocompletion initially. This can happen in a
> different bug.

Ok, I've filed bug 1354504 for that. Though without any autocompletion users won't find out about this feature.

> > And do you plan to add additional filters for information that is currently
> > not visible within the columns in this bug, like e.g. the scheme, or special
> > ones like 'is:from-cache'? Or will that be handled in bug 859047 or a
> > another bug?
> 
> I don't support everything from this list:
> 
> https://github.com/ChromeDevTools/devtools-frontend/blob/
> 16e3b8c8a824315ac2b4c07ca4e4a01fc18f2cea/front_end/network/NetworkLogView.
> js#L1764
> 
> Here are the unsupported fields:
> - cookie-related fields
> - has-response-header
> - mixed-content
> - priority

Should I also file a bug for those?

Sebastian
Assignee: nobody → ntim.bugs
Status: NEW → ASSIGNED
(Assignee)

Updated

a year ago
No longer blocks: 1354504
Depends on: 1354504
No longer depends on: 923192
(Assignee)

Comment 16

a year ago
(In reply to Sebastian Zartner [:sebo] from comment #15)
> (In reply to Tim Nguyen :ntim from comment #9)
> > (In reply to Sebastian Zartner [:sebo] from comment #8)
> > > Yeah, you're right. It should be clear to the users when they explicitly
> > > type 'method:get' that this filters the requests the HTTP method.
> > > 
> > > Two more points:
> > > I believe the autocompletion should be available for both, the filter and
> > > the value, like it's done in Chrome.
> > I don't plan to implement autocompletion initially. This can happen in a
> > different bug.
> 
> Ok, I've filed bug 1354504 for that. Though without any autocompletion users
> won't find out about this feature.
Agreed, thanks for the bug.

> > > And do you plan to add additional filters for information that is currently
> > > not visible within the columns in this bug, like e.g. the scheme, or special
> > > ones like 'is:from-cache'? Or will that be handled in bug 859047 or a
> > > another bug?
> > 
> > I don't support everything from this list:
> > 
> > https://github.com/ChromeDevTools/devtools-frontend/blob/
> > 16e3b8c8a824315ac2b4c07ca4e4a01fc18f2cea/front_end/network/NetworkLogView.
> > js#L1764
> > 
> > Here are the unsupported fields:
> > - cookie-related fields
> > - has-response-header
> > - mixed-content
> > - priority

Priority should be solved by 1354054.
Feel free to file bugs for the others though.
(Assignee)

Updated

a year ago
Duplicate of this bug: 859047
Depends on: 1354507
Depends on: 1354508
Depends on: 1354509
(In reply to Tim Nguyen :ntim from comment #16)
> Priority should be solved by 1354054.
> Feel free to file bugs for the others though.

Ok, I've filed bugs for the others. Btw. what about the 'is' filter?

Sebastian
No longer depends on: 1354507
No longer depends on: 1354508
No longer depends on: 1354509
Thanks for working on this Tim, I like this feature!

@Ricky: can you please do the review?

Just one UX comment. Could we allow spaces between the colon and a value?

For example:
This works: method:GET
This doesn't: method: GET

It took me some time to figure out that the space is not allowed.

Honza
Flags: needinfo?(rchien)
(Assignee)

Comment 20

a year ago
(In reply to Jan Honza Odvarko [:Honza] from comment #19)
> Thanks for working on this Tim, I like this feature!
> 
> @Ricky: can you please do the review?
> 
> Just one UX comment. Could we allow spaces between the colon and a value?
> 
> For example:
> This works: method:GET
> This doesn't: method: GET
> 
> It took me some time to figure out that the space is not allowed.

I think this should be more obvious with autocomplete (bug 1354504), the reason I haven't allowed spaces is that it's not consistent with chrome's UX.
(Assignee)

Comment 21

a year ago
(In reply to Sebastian Zartner [:sebo] from comment #18)
> (In reply to Tim Nguyen :ntim from comment #16)
> > Priority should be solved by 1354054.
> > Feel free to file bugs for the others though.
> 
> Ok, I've filed bugs for the others. Btw. what about the 'is' filter?

That's already supported with this patch.

Comment 22

a year ago
mozreview-review
Comment on attachment 8855696 [details]
Bug 1041895 - Add support for different flags with text filtering.

https://reviewboard.mozilla.org/r/127586/#review130656

Nice job ntim. I noticed there are lots of new feature has added recently. This one is also a good feature everyone wants.

I've verified your patch on my local machine, and it works perfectly. I don't see any big issue here. Let's ship it!

::: commit-message-0895c:1
(Diff revision 4)
> +Bug 1041895 - Add support for different flags with text filtering. r=Honza, gerv

r=rchien

::: devtools/client/netmonitor/src/components/request-list-header.js:22
(Diff revision 4)
>  const WaterfallBackground = require("../waterfall-background");
>  const RequestListHeaderContextMenu = require("../request-list-header-context-menu");
>  
>  const { div, button } = DOM;
>  
> +const { HEADERS } = require("../constants");

nit: move this line before `const { L10N } = require("../utils/l10n");`

::: devtools/client/netmonitor/src/request-list-header-context-menu.js:11
(Diff revision 4)
>  
>  const Menu = require("devtools/client/framework/menu");
>  const MenuItem = require("devtools/client/framework/menu-item");
>  const { L10N } = require("./utils/l10n");
>  
> -const stringMap = {
> +const { HEADERS } = require("./constants");

nit: move this line before `const { L10N } = require("../utils/l10n");`

::: devtools/client/netmonitor/src/request-list-header-context-menu.js:13
(Diff revision 4)
> -};
> +const stringMap = HEADERS.filter(h => h.hasOwnProperty("label"))
> +                    .reduce((acc, h) => {
> +                      acc[h.name] = h.label;
> +                      return acc;
> +                    }, {});

nit: please fix code indentation and avoid to use one character to indicate variable.

How about using Object.assgin to rewrite this part? It makes code look more elegant and functional.

```
const stringMap = HEADERS
  .filter((header) => header.hasOwnProperty("label"))
  .reduce((acc, [name, label]) => Object.assign(acc, { [name]: label }), {});
```

::: devtools/client/netmonitor/src/utils/filter-predicates.js:119
(Diff revision 4)
>    flash: isFlash,
>    ws: isWS,
>    other: isOther,
>  };
>  
> -exports.isFreetextMatch = isFreetextMatch;
> +exports.isFreetextMatch = require("./filter-text-utils").isFreetextMatch;

nit: Let's do require("./filter-text-utils") at the top of file like:

```
const { isFreetextMatch } = require("./filter-text-utils");
```

and then export all properties and methods in one single object pattern:

```
modules.exports = {
  Filters = {
    all: all,
    html: isHtml,
    css: isCss,
    js: isJs,
    xhr: isXHR,
    fonts: isFont,
    images: isImage,
    media: isMedia,
    flash: isFlash,
    ws: isWS,
    other: isOther,
  },
  isFreetextMatch,
};
```

::: devtools/client/netmonitor/src/utils/filter-text-utils.js:34
(Diff revision 4)
> +const HEADER_FILTERS = HEADERS.filter(h => h.canFilter)
> +                              .map(h => h.filterKey || h.name);

nit: indent and some code style

```
const HEADER_FILTERS = HEADERS
  .filter((header) => header.canFilter)
  .map((header) => header.filterKey || header.name);

```

::: devtools/client/netmonitor/src/utils/filter-text-utils.js:46
(Diff revision 4)
> +  "is",
> +];
> +
> +/*
> +  Modified from:
> +  https://github.com/ChromeDevTools/devtools-frontend/blob/f340aefd7ec9b702de9366a812288cfb12111fce/front_end/network/FilterSuggestionBuilder.js#L138-L163

nit: this line exceeded 90 chars
Attachment #8855696 - Flags: review+
Flags: needinfo?(rchien)
Comment hidden (mozreview-request)

Comment 24

a year ago
Pushed by ntim.bugs@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/12b510985e17
Add support for different flags with text filtering. r=rickychien
(In reply to Tim Nguyen :ntim from comment #20)
> (In reply to Jan Honza Odvarko [:Honza] from comment #19)
> > Thanks for working on this Tim, I like this feature!
> > 
> > @Ricky: can you please do the review?
> > 
> > Just one UX comment. Could we allow spaces between the colon and a value?
> > 
> > For example:
> > This works: method:GET
> > This doesn't: method: GET
> > 
> > It took me some time to figure out that the space is not allowed.
> 
> I think this should be more obvious with autocomplete (bug 1354504), the
> reason I haven't allowed spaces is that it's not consistent with chrome's UX.

I think we don't have to align to Chrome's UX here. Allowing (optional) spaces between the colon and the value would be a UX improvement for users.
Having said that, personally I would expect it to work without space, as that's how it works in other search fields like on GitHub or formally on Google Code.

Sebastian

Comment 26

a year ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/12b510985e17
Status: ASSIGNED → RESOLVED
Last Resolved: a year ago
status-firefox55: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 55
Described the different filter flags in https://developer.mozilla.org/en-US/docs/Tools/Network_Monitor#Filtering_by_properties and added a developer release note to https://developer.mozilla.org/en-US/Firefox/Releases/55#Developer_Tools.

Tim, can you please have a look whether the description is ok?

Sebastian
Flags: needinfo?(ntim.bugs)
(Assignee)

Comment 28

a year ago
(In reply to Sebastian Zartner [:sebo] from comment #27)
> Described the different filter flags in
> https://developer.mozilla.org/en-US/docs/Tools/
> Network_Monitor#Filtering_by_properties and added a developer release note
> to https://developer.mozilla.org/en-US/Firefox/Releases/55#Developer_Tools.
> 
> Tim, can you please have a look whether the description is ok?

It seems to be missing some information:
- You can use "-" for negative flag filtering, so "-is:cached" matches all requests that aren't cached
- remote-ip filter is missing
- For size and transferred, it takes the size order (round(log10(number)) rather than just the size, because it's hard to remember the exact size of a file
- the "k" multiplier also works for size and transferred
- the "m" multiplier is also supported for size/transferred/larger-than


Other than that, the docs looks great, thanks!
Flags: needinfo?(ntim.bugs)
(In reply to Tim Nguyen :ntim from comment #28)
> (In reply to Sebastian Zartner [:sebo] from comment #27)
> > Described the different filter flags in
> > https://developer.mozilla.org/en-US/docs/Tools/
> > Network_Monitor#Filtering_by_properties and added a developer release note
> > to https://developer.mozilla.org/en-US/Firefox/Releases/55#Developer_Tools.
> > 
> > Tim, can you please have a look whether the description is ok?
> 
> It seems to be missing some information:
> - You can use "-" for negative flag filtering, so "-is:cached" matches all
> requests that aren't cached
> - remote-ip filter is missing
> - For size and transferred, it takes the size order (round(log10(number))
> rather than just the size, because it's hard to remember the exact size of a
> file
> - the "k" multiplier also works for size and transferred
> - the "m" multiplier is also supported for size/transferred/larger-than
> 
> 
> Other than that, the docs looks great, thanks!

Thank you for the fast reply! I've fixed the documentation accordingly.

The UX of the size and transferred filters feels a bit strange for me. Maybe that should be changed to mean digits, i.e. size:3 means everything between 100 and 999 bytes, or be replaced by a larger-than filter that matches the transferred size instead of the decompressed size, e.g. transferred-larger-than.

Sebastian
Keywords: dev-doc-needed → dev-doc-complete
(Assignee)

Comment 30

a year ago
(In reply to Sebastian Zartner [:sebo] from comment #29)
> (In reply to Tim Nguyen :ntim from comment #28)
> > (In reply to Sebastian Zartner [:sebo] from comment #27)
> > > Described the different filter flags in
> > > https://developer.mozilla.org/en-US/docs/Tools/
> > > Network_Monitor#Filtering_by_properties and added a developer release note
> > > to https://developer.mozilla.org/en-US/Firefox/Releases/55#Developer_Tools.
> > > 
> > > Tim, can you please have a look whether the description is ok?
> > 
> > It seems to be missing some information:
> > - You can use "-" for negative flag filtering, so "-is:cached" matches all
> > requests that aren't cached
> > - remote-ip filter is missing
> > - For size and transferred, it takes the size order (round(log10(number))
> > rather than just the size, because it's hard to remember the exact size of a
> > file
> > - the "k" multiplier also works for size and transferred
> > - the "m" multiplier is also supported for size/transferred/larger-than
> > 
> > 
> > Other than that, the docs looks great, thanks!
> 
> Thank you for the fast reply! I've fixed the documentation accordingly.
> 
> The UX of the size and transferred filters feels a bit strange for me. Maybe
> that should be changed to mean digits, i.e. size:3 means everything between
> 100 and 999 bytes, or be replaced by a larger-than filter that matches the
> transferred size instead of the decompressed size, e.g.
> transferred-larger-than.

Ah, sorry for the confusion, I actually meant it matches depending on the size order.

So: size:120 would match anything from 100 to 999. Same goes for transferred size.

I'm guessing the algorithm could be tweaked a bit to match only from 100 to 200 though in this case. What do you think ?
Flags: needinfo?(sebastianzartner)
(Assignee)

Comment 31

a year ago
> be replaced by a larger-than filter that matches the transferred size instead of the decompressed size, e.g. transferred-larger-than

A transferred-larger-than filter sounds like a good idea as well.
See Also: → bug 1361471
See Also: → bug 1361473
Depends on: 1361480
(In reply to Tim Nguyen :ntim (not accepting requests until 1st June) from comment #30)
> (In reply to Sebastian Zartner [:sebo] from comment #29)
> > (In reply to Tim Nguyen :ntim from comment #28)
> > > (In reply to Sebastian Zartner [:sebo] from comment #27)
> > > > Described the different filter flags in
> > > > https://developer.mozilla.org/en-US/docs/Tools/
> > > > Network_Monitor#Filtering_by_properties and added a developer release note
> > > > to https://developer.mozilla.org/en-US/Firefox/Releases/55#Developer_Tools.
> > > > 
> > > > Tim, can you please have a look whether the description is ok?
> > > 
> > > It seems to be missing some information:
> > > - You can use "-" for negative flag filtering, so "-is:cached" matches all
> > > requests that aren't cached
> > > - remote-ip filter is missing
> > > - For size and transferred, it takes the size order (round(log10(number))
> > > rather than just the size, because it's hard to remember the exact size of a
> > > file
> > > - the "k" multiplier also works for size and transferred
> > > - the "m" multiplier is also supported for size/transferred/larger-than
> > > 
> > > 
> > > Other than that, the docs looks great, thanks!
> > 
> > Thank you for the fast reply! I've fixed the documentation accordingly.
> > 
> > The UX of the size and transferred filters feels a bit strange for me. Maybe
> > that should be changed to mean digits, i.e. size:3 means everything between
> > 100 and 999 bytes, or be replaced by a larger-than filter that matches the
> > transferred size instead of the decompressed size, e.g.
> > transferred-larger-than.
> 
> Ah, sorry for the confusion, I actually meant it matches depending on the
> size order.
> 
> So: size:120 would match anything from 100 to 999. Same goes for transferred
> size.
> 
> I'm guessing the algorithm could be tweaked a bit to match only from 100 to
> 200 though in this case. What do you think ?

I've filed bug 1361480 to improve the algorithm, so we can discuss this separately.

(In reply to Tim Nguyen :ntim (not accepting requests until 1st June) from comment #31)
> > be replaced by a larger-than filter that matches the transferred size instead of the decompressed size, e.g. transferred-larger-than
> 
> A transferred-larger-than filter sounds like a good idea as well.

Great! I've filed bug 1361473 for it.

Sebastian
Flags: needinfo?(sebastianzartner)
See Also: bug 1361471

Comment 33

a year ago
I have reproduced this bug with Nightly 55.0a1 (2014-07-21) on Windows 8.1 , 64 Bit ! 

This bug's fix is Verified with latest Nightly 55.0a1 !

Build   ID    20170528030206
User Agent    Mozilla/5.0 (Windows NT 6.3; WOW64; rv:55.0) Gecko/20100101 Firefox/55.0

[bugday-20170524]
(Assignee)

Updated

a year ago
Status: RESOLVED → VERIFIED
status-firefox55: fixed → verified
You need to log in before you can comment on or make changes to this bug.