davidmcgregor@ can you please provide us with a reduced testcase i.e, an URL which we can use for further triage.

I have same problem. We can reduced by Xdebug with PHP.

https://stackoverflow.com/questions/46091632/chrome-developer-tools-cannot-show-pre-tag-in-network-preview-tab

The problem also exists when the server returns json string. In chrome 60 the json string presented it in a beautiful way like json object. 
When you print a variable with var_dump from php with xdebug, Chromoe 61 does not correctly read the html generated by xdebug and displays the information in a single line.
Please view the attached file for more info.

Deleted: 763921.pdf 351 KB

763921.pdf 351 KB Download

I don't really have a URL you can use unfortunately. You'll have to just set up a simple php server or a nodejs server and just echo out plain text.

Thank you for providing more feedback. Adding requester "pbommana@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

#4 - can you upload a small static test case in GitHub? Then you can use GitHub Pages or rawgit.com to serve that test case.

Oops, I meant #5.

If you provide a reproducible test case, it will be triaged and fixed sooner than if you do not, so if you have any interest in it being resolved, you can expedite it.

I understand, but it does not work by accessing json or other files. I only know how to reproduce with a web server and using an xhr request.

I have tested with a gist and it works as would be expected.

Also worth noting:
If I take the request that does not format properly and open in a new tab or make a fetch() request from the console, it is formatted correctly.

Okay perfect I am able to reproduce easily:

Stick this into an index.php file in some test folder:

<?php
header("Content-Type: text/html; charset=UTF-8");
header('HTTP/1.1 500 Internal Server Error');

$myArray = [1, 2, 3, 4, "TEST"];

var_dump($myArray);die();


Then navigate to the folder and (with php installed) run php -S localhost:8000

You will be able to see that the text is both black and unformatted in your dev tools preview tab.

#12 - why would it be formatted? You serve HTML content (text/html) without any <br/>, <style>, CSS of any other kind, or any other formatting information.
I expect the Response tab to show the line breaks and the Preview tab to show a single line.

And using <pre> also seems to work (go to some website - not this issue tracker since it uses content security policy that restricts my code - enter this in the console and explore the Network entry) -
fetch("data:text/html;charset=utf-8," + escape("<pre>j              3                  \n\n</pre>")).then(r => r.text())

var_dump wraps the output like so:

<pre class='xdebug-var-dump' dir='ltr'>
<small>test\index.php:7:</small>
array <i>(size=5)</i>
  0 <font color='#888a85'>=&gt;</font> <small>int</small> <font color='#4e9a06'>1</font>
  1 <font color='#888a85'>=&gt;</font> <small>int</small> <font color='#4e9a06'>2</font>
  2 <font color='#888a85'>=&gt;</font> <small>int</small> <font color='#4e9a06'>3</font>
  3 <font color='#888a85'>=&gt;</font> <small>int</small> <font color='#4e9a06'>4</font>
  4 <font color='#888a85'>=&gt;</font> <small>string</small> <font color='#cc0000'>'TEST'</font> <i>(length=4)</i>
</pre>

The trick was to add header('HTTP/1.1 500 Internal Server Error');

@phistuck:

In previous version of Chrome, the Preview tab displays the formatted code.
You can test with davidmcg's trick like this:
1. Download version 60.0.3109.0 of Chromium (https://sourceforge.net/projects/crinstaller/files/chromium_60.0.3109.0_windows-setup_x64.exe/download?use_mirror=jaist)

2. Create test.php file like this:

<?php
header("Content-Type: text/html; charset=UTF-8");
header('HTTP/1.1 500 Internal Server Error');
?>
<pre class='xdebug-var-dump' dir='ltr'>
<small>test\index.php:7:</small>
array <i>(size=5)</i>
  0 <font color='#888a85'>=&gt;</font> <small>int</small> <font color='#4e9a06'>1</font>
  1 <font color='#888a85'>=&gt;</font> <small>int</small> <font color='#4e9a06'>2</font>
  2 <font color='#888a85'>=&gt;</font> <small>int</small> <font color='#4e9a06'>3</font>
  3 <font color='#888a85'>=&gt;</font> <small>int</small> <font color='#4e9a06'>4</font>
  4 <font color='#888a85'>=&gt;</font> <small>string</small> <font color='#cc0000'>'TEST'</font> <i>(length=4)</i>
</pre>

3. Run that test.php file in Chrome 61.0.3163.79 and Chromium 60.0.3109.0 to see the difference when browsing Preview tab

Able to reproduce the issue on Mac 10.12.6 with chrome Stable & Beta # 61.0.3163.79 but not on Dev #62.0.3202.18, Canary #63.0.3213.3

Issue is broken in M61 and Fixed in M62.

Broken Bisect Info :
Good build : 61.0.3137.0, Revision Range -481056
Bad build  : 61.0.3138.0, Revision Range -481386

Broken CL:
https://chromium.googlesource.com/chromium/src/+log/2596c5101b8b875c48fb6eed2461ef0f7eff838b..b8894a5a53943461944899421f1264c33a5a933e

Suspect CL: https://chromium-review.googlesource.com/538233

*********************************

Fixed Bisect Info :
Good build : 62.0.3193.0, Revision Range -496151
Bad build  : 62.0.3192.0, Revision Range -495856

Fixed CL: 
https://chromium.googlesource.com/chromium/src/+log/87d7e6ddb22a1cf4916fcbb74b293ee5a8fa6227..71d5b3a8bd92e6ce9ff33a21c43b76e0be94e6b4

Suspect CL: https://chromium-review.googlesource.com/616664

allada@,mkwst@- Could you please look into this issue and merge the fix in upcoming beta and stable builds.

Note:
Unable to test the issue on Window 10 & Ubuntu 14.04 because of unavailability of test setup.

Thank You...

Deleted: 763921-M62-Good.png 122 KB

	763921-M62-Good.png 122 KB View Download

Deleted: 763921-M62-Bad.png 121 KB

	763921-M62-Bad.png 121 KB View Download

Deleted: 763921-M61-Good.png 133 KB

	763921-M61-Good.png 133 KB View Download

Deleted: 763921-M61-Bad.png 130 KB

	763921-M61-Bad.png 130 KB View Download

From the above bisect info, issue appears to be broken in M61, but again fixed on M62 & M63 canary. Tagged with blocker label for M61. 

Can this be addressed.

Thanks.!

pfeldman@ can you please take a look at this issue since as per our offline chat we never formatted data automatically.

Looks like whitespace are now stripped from the data, while previously we preserved \n characters? Sounds like a valid regression. Not sure it's worth a stable merge though.

--- Postmortem ---

1. The https://chromium-review.googlesource.com/616664 refactored DevTools preview view, and during refactoring it stopped unconditionally encoding response as base64 for data urls.

2. Unfortunately, newlines were stripped out of the data URLs. Thus the regression happened.

3. 3 weeks ago https://chromium-review.googlesource.com/c/chromium/src/+/616664 stopped removing newlines from data URLs for unrelated reasons.

--- ---

Summary:
* This is fixed on tip-of-tree
* The issue was happening only in case of error responses.

I don't think this is a release-block stable.

To be on the safe side, DevTools need to unconditionally encode response as base64 so that we don't miss anything next time. Over to @allada.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2a04495525d82b290a619c4abd62067e9fa79bad

commit 2a04495525d82b290a619c4abd62067e9fa79bad
Author: Nathan Bruer <allada@chromium.org>
Date: Thu Sep 28 23:42:01 2017

[Devtools] Regression: Fixed rendering of HTML and JSON in network

* Fixed bug where network preview would not render JSON if it was
fetched and and had an error code.

* Fixed bug where network preview would try to render as  HTML
agressively if requested via XHR.

R=pfeldman,eostroukhov
BUG= 765286 , 767393 , 763921 

Change-Id: I9a160e50241e406456623469738b0694800ae586
Reviewed-on: https://chromium-review.googlesource.com/687890
Reviewed-by: Pavel Feldman <pfeldman@chromium.org>
Commit-Queue: Blaise Bruer <allada@chromium.org>
Cr-Commit-Position: refs/heads/master@{#505212}
[modify] https://crrev.com/2a04495525d82b290a619c4abd62067e9fa79bad/third_party/WebKit/LayoutTests/http/tests/devtools/network/network-choose-preview-view-expected.txt
[modify] https://crrev.com/2a04495525d82b290a619c4abd62067e9fa79bad/third_party/WebKit/LayoutTests/http/tests/devtools/network/network-choose-preview-view.html
[modify] https://crrev.com/2a04495525d82b290a619c4abd62067e9fa79bad/third_party/WebKit/Source/devtools/front_end/network/RequestPreviewView.js

 Issue 767386  has been merged into this issue.

Is this need a merge to M62?

#27 I am pushing on another bug for this to be merged BUG= 767393 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f674b40baf2d44d1b27f33b3ed39e60b2b9169da

commit f674b40baf2d44d1b27f33b3ed39e60b2b9169da
Author: Blaise <allada@chromium.org>
Date: Tue Oct 03 20:17:01 2017

[Devtools] Regression: Fixed rendering of HTML and JSON in network

* Fixed bug where network preview would not render JSON if it was
fetched and and had an error code.

* Fixed bug where network preview would try to render as  HTML
agressively if requested via XHR.

R=pfeldman,eostroukhov
BUG= 765286 , 767393 , 763921 

(cherry picked from commit 2a04495525d82b290a619c4abd62067e9fa79bad)

Change-Id: I9a160e50241e406456623469738b0694800ae586
Reviewed-on: https://chromium-review.googlesource.com/687890
Reviewed-by: Pavel Feldman <pfeldman@chromium.org>
Commit-Queue: Blaise Bruer <allada@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#505212}
Reviewed-on: https://chromium-review.googlesource.com/698906
Reviewed-by: Blaise Bruer <allada@chromium.org>
Cr-Commit-Position: refs/branch-heads/3202@{#561}
Cr-Branched-From: fa6a5d87adff761bc16afc5498c3f5944c1daa68-refs/heads/master@{#499098}
[modify] https://crrev.com/f674b40baf2d44d1b27f33b3ed39e60b2b9169da/third_party/WebKit/Source/devtools/front_end/network/RequestPreviewView.js

 Issue 760278  has been merged into this issue.

Verified this issue on Mac 10.12.6 with chrome Beta #62.0.3202.45, followed steps mentioned in the comment #18

Observed that text is formatted properly and flowing vertically.

Attaching the screen-cast for reference.Hence adding TE-Verified labels.

Deleted: 763921.png 123 KB

	763921.png 123 KB View Download

I see the bug was fixed but what is the difference about the "Preview" tab and "Response" tab when the response body is HTML?

Following this issue, I see the response body with error header will be formatted but the response body without error header will be not.

I think PHP developers who are familiar with XDebug will confuse about this behavior because when they *var_dump* something without error header, they will have a messy HTML code.

Is it normal behavior?

Issue again on chrome 62.0.3202.75

Still an issue in DEV 64.0.3251.0  and beta 63.0.xxx

Problem not fixed yet version used 64.0.3254.0

Problem not fixed yet version used 62.0.3202.94 (Official Release) and Canary too

There is still a problem

Deleted: chrome_issue.PNG 72.0 KB

	chrome_issue.PNG 72.0 KB View Download

This is still a problem. For test case:

1. Open Dev Tools
2. Go to Network Panel
3. Load google.com
4. Click the "www.google.com" request and select Preview tab
5. Code is displayed instead of a rendered view of the page that should match the main browser window

Don't know why but I test two files and have two results. So this is still a problem.

1. Passed.
----------------------------------
<?php
header("Content-Type: text/html; charset=UTF-8");
header('HTTP/1.1 500 Internal Server Error');
?>
<pre class='xdebug-var-dump' dir='ltr'>
<small>test\index.php:7:</small>
array <i>(size=5)</i>
  0 <font color='#888a85'>=&gt;</font> <small>int</small> <font color='#4e9a06'>1</font>
  1 <font color='#888a85'>=&gt;</font> <small>int</small> <font color='#4e9a06'>2</font>
  2 <font color='#888a85'>=&gt;</font> <small>int</small> <font color='#4e9a06'>3</font>
  3 <font color='#888a85'>=&gt;</font> <small>int</small> <font color='#4e9a06'>4</font>
  4 <font color='#888a85'>=&gt;</font> <small>string</small> <font color='#cc0000'>'TEST'</font> <i>(length=4)</i>
</pre>
----------------------------------

2. Failed:
----------------------------------
<?php
header("Content-Type: text/html; charset=UTF-8");
header('HTTP/1.1 500 Internal Server Error');
?>
<pre class='xdebug-var-dump' dir='ltr'>
<small>C:\wamp\www\tools\Debug.php:68:</small>
object(<i>mysqli</i>)[<i>307</i>]
  <i>public</i> 'affected_rows' <font color='#888a85'>=&gt;</font> <small>int</small> <font color='#4e9a06'>0</font>
  <i>public</i> 'client_info' <font color='#888a85'>=&gt;</font> <small>string</small> <font color='#cc0000'>'mysqlnd 5.0.11-dev - 20120503 - $Id: 76b08b24596e12d4553bd41fc93cccd5bac2fe7a $'</font> <i>(length=79)</i>
  <i>public</i> 'client_version' <font color='#888a85'>=&gt;</font> <small>int</small> <font color='#4e9a06'>50011</font>
  <i>public</i> 'connect_errno' <font color='#888a85'>=&gt;</font> <small>int</small> <font color='#4e9a06'>0</font>
  <i>public</i> 'connect_error' <font color='#888a85'>=&gt;</font> <font color='#3465a4'>null</font>
  <i>public</i> 'errno' <font color='#888a85'>=&gt;</font> <small>int</small> <font color='#4e9a06'>0</font>
  <i>public</i> 'error' <font color='#888a85'>=&gt;</font> <small>string</small> <font color='#cc0000'>''</font> <i>(length=0)</i>
  <i>public</i> 'error_list' <font color='#888a85'>=&gt;</font>
    <b>array</b> <i>(size=0)</i>
      <i><font color='#888a85'>empty</font></i>
  <i>public</i> 'field_count' <font color='#888a85'>=&gt;</font> <small>int</small> <font color='#4e9a06'>0</font>
  <i>public</i> 'host_info' <font color='#888a85'>=&gt;</font> <small>string</small> <font color='#cc0000'>'127.0.0.1 via TCP/IP'</font> <i>(length=20)</i>
  <i>public</i> 'info' <font color='#888a85'>=&gt;</font> <font color='#3465a4'>null</font>
  <i>public</i> 'insert_id' <font color='#888a85'>=&gt;</font> <small>int</small> <font color='#4e9a06'>0</font>
  <i>public</i> 'server_info' <font color='#888a85'>=&gt;</font> <small>string</small> <font color='#cc0000'>'2.2.11-id64-release (95ae9a6)'</font> <i>(length=29)</i>
  <i>public</i> 'server_version' <font color='#888a85'>=&gt;</font> <small>int</small> <font color='#4e9a06'>20211</font>
  <i>public</i> 'stat' <font color='#888a85'>=&gt;</font> <small>string</small> <font color='#cc0000'>'�#08S01unknown command (code=9)&#0;'</font> <i>(length=34)</i>
  <i>public</i> 'sqlstate' <font color='#888a85'>=&gt;</font> <small>string</small> <font color='#cc0000'>'00000'</font> <i>(length=5)</i>
  <i>public</i> 'protocol_version' <font color='#888a85'>=&gt;</font> <small>int</small> <font color='#4e9a06'>10</font>
  <i>public</i> 'thread_id' <font color='#888a85'>=&gt;</font> <small>int</small> <font color='#4e9a06'>1</font>
  <i>public</i> 'warning_count' <font color='#888a85'>=&gt;</font> <small>int</small> <font color='#4e9a06'>0</font>
</pre>
----------------------------------

Version: 62.0.3202.94 (Official Build) (64-bit)

Still an issue in Chrome Canary 65.0.3285.0 and Chrome 62.0.3202.94

Still an issue in 63.0.3239.108 macOS

Deleted: Screen Shot 2017-12-21 at 13.58.50.png 206 KB

	Screen Shot 2017-12-21 at 13.58.50.png 206 KB View Download

For Laravel developers: https://github.com/laravel/framework/pull/22581

Still an issue

Still an issue.  This bug should be reopened.

I think there's some confusion in this bug over the DESIGNED behavior. See   Issue 785050  and  Issue 778581  where it is noted that the Developer Tools' PREVIEW tab is designed to generally show code (markup), not rendered html.

I relied on the Preview tab rendering even a basic layout of HTML up to Chrome 60 to render html in human readable data when retrieving something via XHR when the backend returns an error especially. The backend I develop on returns errors in HTML formatting, which means I then have to copy the response or preview out to a notepad, save it and open it again in order to read it without giving myself a headache.

I know I'm not the only one having this issue or considers the current behavior of the Preview tab to be a bug.

It does render JSON responses in very useful object format, but it has always done that, and the current behavior doesn't help at all when something goes wrong.

It may be something that the devs designed this way, but it's not overly helpful that it is designed this way.

@elawre Then what purpose does it serve having a PREVIEW and a RESPONSE tab? One of those tabs is clearly intended to render the code otherwise you can get rid of the duplicate functionality.