Maxim Reporter
	Description • 7 years ago

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170212030213

Steps to reproduce:

Open developer tools.
Open network pane.
Reload page.




Actual results:

Column file contains only names.


Expected results:

Option to show full url paths. It is very important feature.. We cannot see which API was really called...

	Ricky Chien [:rickychien] (inactive)
	Comment 1 • 7 years ago

Maxim, IMO this feature is by designed. Full url path will be very very long so that it is impossible to show up on network monitor entirely.

Full path will be displayed in tooltip as you hover the mouse on file name.

Thank you for reporting this. Thanks!

	YF (Yang)
	Comment 2 • 7 years ago

(In reply to Ricky Chien [:rickychien] from comment #1)
> Maxim, IMO this feature is by designed. Full url path will be very very long
> so that it is impossible to show up on network monitor entirely.

Possibility to .../path/name and click/double-click to display on a read-only text field? Like a spreadsheet.

	Maxim Reporter
	Comment 3 • 7 years ago

>Maxim, IMO this feature is by designed. Full url path will be very very long so that it is impossible to show up on network monitor entirely.

Please give us an option in settings...
For XHR it is not actual at all because mostly always we use POST to pass parameters.
Even with GET it is not so much long...
Also we have 24"-32" monitors. So long path is not the case...

But I can suggest to make the following options in settings:

[ ] Show domain names only (as it is now)
[ ] Show reduced path (path with slash but without parameters after ? if you think it can be reason to be long)
[ ] Show full path only (I need only this one, very long paths simply can be trimmed by screen width)

But I personal think length is not a problem and mostly all paths in related apps looks like:
https://some-domain.net/api/testing/load

maximum it can be like:
https://some-domain.net/api/testing/load/some-id

So your solution does not show very needed info: "api/testing/load"
And if I need to check what app calls I have to manually inspect each request.
It can be 10-20 requests and I do not have a way to look and analyze at once.

It looks like we have room there but we do not use it to show info... looks very very strange.

	Maxim Reporter
	Comment 4 • 7 years ago

Guys please reopen this issue!

It is very annoying...
And I see similar questions from community:
FF: https://stackoverflow.com/questions/41945654/show-full-uri-url-in-firefox-developer-tools-console-tab
Chrome: https://superuser.com/questions/393088/show-full-uri-url-in-chromes-developer-tools-network-tab

If Chrome will implement it first it will be +100 in score.. and I will have to use Google browser.

I do not see any reason why it cannot be displayed: https://snag.gy/pHAOrj.jpg

It has enough room there... and it can make developers much more productive.
It is absolutely not possible to track API calls in the way how it is now (move mouse to show tooltip for each XHR).
So in my example I do not know which is "load" request without full url.
If I have 5-10 similar requests then it becomes a HELL in daily work.

	Ricky Chien [:rickychien] (inactive)
	Comment 5 • 7 years ago

Hey Maxim,

Thanks for your feedback! I can know this feature seems very handy for developers. I'm going to reopen this as you wish and see what we can tweak for the current inappropriate design.

Honza, as Maxim mentioned, I think showing the full file path is reasonable. How do you think?

	Ricky Chien [:rickychien] (inactive)
	Comment 6 • 7 years ago

Honza is PTO until 8/6, let's wait for his feedback.

	Jan Honza Odvarko [:Honza] (always need-info? me)
	Comment 7 • 7 years ago

I totally agree that having the full path visible is very useful. At the same time, I think that we should try hard to come up with UI/UX that does *not* need a new preference (and three prefs for this relatively small feature is huge).

Here is how I see it.

* The network panel uses tabular layout to show detailed info about HTTP traffic and individual columns are not best to fit URLs. The trend these days is to rather append more columns and even if dev folks are using bigger monitors it doesn't seem to be the right way to go. The best thing here is to introduce (at least) a tooltip with full URL.

* But, the Console panel is different story. It also displays HTTP events/logs and these are *not* using tabular layout. XHR log in the Console should be mostly the (full) URL and basic timing (how much time it took to get the response back), size and an indicator/spinner showing whether the request is still in progress. HTTP logs in the Console should be expandable (already planned) so, all the HTTP details are available quickly without necessity to switch to the Net panel and back.

So, I believe we should support this feature in the Console panel.

Honza

	Maxim Reporter
	Comment 8 • 7 years ago

>we should try hard to come up with UI/UX that does *not* need a new preference
It is reasonable... If it is possible then I agree.

>The best thing here is to introduce (at least) a tooltip with full URL.
Tooltip is already there... look at my image. And it does not help... 
It does not allow to monitor(!) activity.
So I constantly move mouse over File items to get info.

>So, I believe we should support this feature in the Console panel.
Not sure it is good idea...
1) You can get a lot of details in console.
So requests will not be visible good.
Let's say you got 404 and then some very detailed exception in logic.

2) Sometimes developer can expect only console.log output...
He will not very happy with tons of requests info (if they are not required in the moment).

There are no "magic switchers" in console to switch from "console mode" to "net mode".
You have to go through sub-menu in console and set each desired option.
Maybe some predefined presets can help here...
But I am not sure that it is something more easy than 1-2 options in settings for network tab.

In any case I will try to explain briefly how we use network monitor.
First of all it is the way to view what happens with app.
It is good way to understand lifecycle.. to check interaction with server.
I can see there which status code returned.. was it cached or not...
Which headers are sent / received... and which payload / response is transferred.
How much size for each request... which request is biggest... (a bit annoying when 304 is included as transferred total).
And what after what is requested and delivered to/from client.

I do not think we need console instead network monitor.
Otherwise Console will become network monitor... and in my opinion it is bad idea.
So as you can see we need a lot of network features.. for example filter of XHR... 
And console does not look a good place for such features.

	Pulsebot
	Comment 19 • 5 years ago

Pushed by jodvarko@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c1d2feb784e0
Show full path in File column in developer tools. r=Honza