1590433 - wrap (or maybe force-wrap) for network request's response payload

Status: NEW

(DevTools :: Netmonitor, enhancement, P3)

Description

[Ardeshir Izadi]

Attachment: ff.png

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0

Steps to reproduce:

sent an ajax request that contained a long (one-line maybe) string

Actual results:

request's Response Payload section has only one line (which is correct) and a very long horizontal scroll (which is annoying)

Expected results:

It should have a wrap (or even force-wrap, in case response payload has no spaces) option to wrap the response payload, so I wouldn't have to drag the scrollbar with mouse and move it all along horizontal pane.

If I have wrap enabled, I don't have lots of waste free space and also my middle mouse scroll would work.

Comment 1

[Jan Honza Odvarko [:Honza] (always need-info? me) PTO July 8 - 26]

Harald, perhaps we could work on this now when we are working on the Response panel?
This would make inspection of large one-line response so much easier.

This would be easy to fix since CodeMirror supports it.

So, it's only a UI question. We could have and option somewhere:

• a context menu item (this could be simple way to move forward)
• a toggle button within the Accordion section header
• a button in the toolbar (as soon as we have it)
• combination of above.

We can do simple thing here and reiterate after user feedback...

Honza

Comment 2

[:Harald Kirschner :digitarald]

I had the same thought when fixing bug 1618996 and adding back the overflow behavior. Line-wrap by default might make sense for most users, as side-ways scrolling in responses in pervasive.

Smarter pretty-printing would also help with many cases of long JSON or HTML – but then again this is solved by the formatted version of the payload.

Related, bug 1590885 is exposing the option for Debugger.

Should we try to enable wordwrap by default in code mirror? I wonder if it has performance impact, as I saw issues before.

Comment 3

[Jan Honza Odvarko [:Honza] (always need-info? me) PTO July 8 - 26]

Should we try to enable wordwrap by default in code mirror?

Agreed, that make sense for me.

I wonder if it has performance impact, as I saw issues before.

I thinkg that rendering huge one line text in CM can actually be a perf issue.
Let me ask around

Honza

Comment 4

[Hubert Boma Manilla (:bomsy)]

Attachment: Screenshot 2020-03-24 at 15.47.08.png

After looking at the perf profiles

It seems like wrapping does not improve performance, it seems to slightly make it slightly worse
as it has to call updateCodeFoldingGutter when wrapping is enabled.
See screenshot

Profiles
Diff of both:
https://perfht.ml/2UhQgVo

Without wrapping:
https://perfht.ml/2vLCqB7

With wrapping:
https://perfht.ml/3aj0l9Z

Comment 5

[:Harald Kirschner :digitarald]

Bomsy, is that testing with a larger file? I wonder if it improves rendering of minified files with extra long lines.

Comment 6

[Hubert Boma Manilla (:bomsy)]

Harald,
A test with a larger minified file, shows it is slightly slower for the initial render, so wrapping definitely does a little more.
Having said that, it does not seem to be determined by the size of the content though.

So far I've not been able to completely determine if virtualization is happening or not
One reason might be because the first line is always selected by default, this might cause all the wrapped content to render for selection.

I'll dig further with an unminified version of codemirror, to see what exactly codemirror is doing.

Comment 7

[:Harald Kirschner :digitarald]

If it is really just "slightly", it seems we are good in moving forward with codemirror as it gives us more features and consistent cursor/copy/scroll behavior.