903465 - Allow seeing the actual request path rather than just the file name in the Network Monitor

Status: RESOLVED DUPLICATE of bug 1162677

(DevTools :: Netmonitor, defect, P3)

Description

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Attachment: Screen Shot 2013-08-09 at 11.21.03 AM.png

See the attached screenshot.

I am trying to find out what the last XHR request actually looks like. Unfortunately it is impossible to see the full path of the request:

1) The list of network requests shows '/?...' in the 'File' column, which is incorrect and incomplete.

2) The pane on the right truncates the 'Request URL' and doesn't allow you to select or copy it.

Comment 1

[Victor Porof [:vporof][:vp]]

You can hover the request and see a tooltip with the full path, or use right click + "Copy url".

Comment 2

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Yeah that is not really a solution. Then the tools just get in the way. This is pretty basic info that you always want to see when looking at network requests ...

Isn't it possible to either include the path in the File column or add a new column to show it?

Comment 3

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Actually, isn't this a bug in the url parser? The requests in my screenshot all have a Path/File component but all that is shown as the File is '/' plus the query string. Isn't that a bug?

Comment 4

[Victor Porof [:vporof][:vp]]

Can you please paste the full url?

Comment 5

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

URLs:

https://marketplace-dev.allizom.org/api/v1/apps/rating/?app=soundcloud&lang=en-US&pro=3040fe.32.1&region=us

https://marketplace-dev.allizom.org/api/v1/fireplace/app/soundcloud/?lang=en-US&pro=3040fe.32.1&region=us

Maybe the /? is confusing it?

Comment 6

[Victor Porof [:vporof][:vp]]

Well, the parser is right about this, not confused. Strictly speaking, there's no "fileName" in the url, but an empty leaf with params directly following it. It would be wrong to include, say "rating/?..." because that's part of the path.

Comment 7

[Panos Astithas (he/him) [:past] (please ni?)]

Maybe we shouldn't be sticking so closely to the file metaphor in the network panel. Web apps use a REST architecture more often than not, which deals with "resources", not "files", that may have one or more representations that correspond to files. You don't deal with a file when you make an XHR to retrieve your Facebook social graph, for example.

Comment 8

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

(In reply to Panos Astithas [:past] from comment #7)
> Maybe we shouldn't be sticking so closely to the file metaphor in the
> network panel. Web apps use a REST architecture more often than not, which
> deals with "resources", not "files", that may have one or more
> representations that correspond to files. You don't deal with a file when
> you make an XHR to retrieve your Facebook social graph, for example.

Note that even though I mentioned XHR in this bug, it is really about any type of request.

I want to easily see the full path of any type of request. Not just the last part of it.

When I work on web apps or do a web app security review that is something I need to see. Ideally without having to open an inspector.

How about giving people the choice to add a Path column.

 S.

Comment 11

[Anton Bobrov]

Attachment: netmonitor-file-path.patch

Patch to show full path names instead file names.

Comment 12

[Anton Bobrov]

And simple script to patch system omni.ja:

------
#!/bin/bash
set -e
omni=${1:-/usr/lib/firefox/browser/omni.ja}
workdir=/tmp/patch-fox.tmp

[ -f "$omni" ] || { echo "$omni not found"; exit 1; }

[ -d $workdir ] && rm -rf $workdir
mkdir $workdir

cd $workdir
unzip -q "$omni" || true

cat <<EOF | patch -p1
diff -aur orig/chrome/browser/content/browser/devtools/netmonitor-view.js new/chrome/browser/content/browser/devtools/netmonitor-view.js
--- orig/chrome/browser/content/browser/devtools/netmonitor-view.js     2010-01-01 00:00:00.000000000 +0300
+++ new/chrome/browser/content/browser/devtools/netmonitor-view.js      2014-09-18 21:23:38.047201746 +0400
@@ -1654,7 +1654,7 @@
     if (!(aUrl instanceof Ci.nsIURL)) {
       aUrl = nsIURL(aUrl);
     }
-    let name = NetworkHelper.convertToUnicode(unescape(aUrl.fileName)) || "/";
+    let name = NetworkHelper.convertToUnicode(unescape(aUrl.filePath)) || "/";
     let query = NetworkHelper.convertToUnicode(unescape(aUrl.query));
     return name + (query ? "?" + query : "");
   },
EOF

zip -qr9XD omni.ja *
echo "Going to replace $omni ..."
sudo cp omni.ja "$omni"
echo "Done"
firefox --purgecaches
-------

Comment 13

[John Chadwick[:jchw]]

I concur with the notion that a path would be more useful than a file. When trying to wade through a large number of RESTful requests, a bunch of /?... is completely, absolutely useless.

Comment 14

[kiril]

We have a patch that fixes this for some time now. I will try with another push to get this merged :)

Comment 15

[Jan Keromnes [:janx]]

This was recently fixed by Jarda Snajdr in bug 1162677.

(In reply to Stefan Arentz [:st3fan] from comment #0)
> 
> 1) The list of network requests shows '/?...' in the 'File' column, which is
> incorrect and incomplete.

For resource paths ending with "/", the full path is now shown (e.g. "/api/new/?a=b" instead of "/?a=b")

> 2) The pane on the right truncates the 'Request URL' and doesn't allow you
> to select or copy it.

You can now see the whole URL as a tooltip by hovering over any element (drive-by fix in the same bug).