Closed Bug 903465 Opened 6 years ago Closed 4 years ago

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

Categories

(DevTools :: Netmonitor, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1162677

People

(Reporter: st3fan, Unassigned)

References

Details

(Whiteboard: [polish-backlog])

Attachments

(2 files)

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.
You can hover the request and see a tooltip with the full path, or use right click + "Copy url".
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?
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?
Can you please paste the full url?
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.
OS: Mac OS X → All
Priority: -- → P3
Hardware: x86 → All
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.
(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.
Duplicate of this bug: 1024406
Summary: It is impossible to see the actual request path → Allow seeing the actual request path rather than just the file name in the Network Monitor
Duplicate of this bug: 1048015
Patch to show full path names instead file names.
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
-------
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.
We have a patch that fixes this for some time now. I will try with another push to get this merged :)
Whiteboard: [devedition-40]
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).
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1162677
Whiteboard: [devedition-40] → [polish-backlog]
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.