Thanks for the report.  I'm not aware of when DevTools used to preview the rendered HTML in Network panel.  At least as far back as Chrome 50.0.2661.0, the Network panel seems to just show the source code text of documents.

The "Response" view in the Network panel should show the raw source code and the "Preview" should render the view. I've been using this feature for over 2 years now and the recent update broke it.

"Unable to reproduce the issue on the reported chrome version 62.0.3202.94 using Windows 10 with the below mentioned steps.
1. Opened Chrome
2. Pressed F12 to open dev tools
3.Loaded a web page
4.Opened network tab and pressed F5 to load then selected preview.
We observed the html rendered properly in the preview. Attaching the screen cast of the same.

@Reporter: Could you please check the screen cast and let us know if we have missed any steps in reproducing the issue. 

Thanks!"

Deleted: 785050.mp4 1.7 MB

	785050.mp4 1.7 MB View Download

@vamshi.k...@techmahindra.com
The comment before yours, explains it quite nice: the Preview tab should show the *rendered* content, not the source code. For the source code, there is the Response tab.
A lot of people do not understand why this is needed (actually the same feature was removed from Firefox [and subsequently restored], because the developers taught the Preview and Response tab duplicated the same functionality).
So let me give you an example of my usage case: I recently was debugging a from, that was being submitted trough an ajax request. When the form was sent, a JSON formated response was expected, but there was an error (a missing semicolon) in the back-end script, that handled the form submission. The back-end script is part of a framework and the framework used stylized error messages for those errors, and that meant a lot of html with inlined css and javascript - this is unreadable if you try to read it trough the source code view. So I needed the rendered version, that is the version, that is all nice and readable for a human being.
The Preview tab is like having a webview panel, where you can see how, the data that was received, would look like in a browser.

As yanosh.k@gmail.com suggested the rendered "Preview" view is very important when developing with frameworks. Many frameworks will add superfluous html  when dumping data or when an error is encountered to help make the data easier to read. With the current "Preview" tab all that html is making it impossible to read the data dumps or errors.

There is a distinction between the "Preview" and "Response" tab that keeps getting missed in the discussion here. The "Response" tab in the Network panel should show the raw source code and the "Preview" tab should render the view as it would appear in the browser window. Currently both tabs are displaying source code.

If there was a way for me to rollback my version I could provide an example in action.

Here is an example of the "Preview" working as intended rendering the HTML and the "Response" showing the source code

Deleted: previe_example.PNG 78.6 KB

	previe_example.PNG 78.6 KB View Download

Deleted: response_example.PNG 111 KB

	response_example.PNG 111 KB View Download

For a 'easy' test case : 

Go to : https://www.test-cors.org/#?client_method=GET&client_credentials=false&server_url=google.be&server_enable=true&server_status=200&server_credentials=false&server_tabs=remote

This will make make a xhr request to google.be

chrome 60.0.3112.78 the 'preview tab' show parsed html
chrome 63.0.3239.18 the 'preview tab' show raw html

Please see the attached screenshot.

(sorry for my bad english ...)

Deleted: chrome.60.0.3112.78.OK.PNG 25.1 KB

	chrome.60.0.3112.78.OK.PNG 25.1 KB View Download

Deleted: chrome.63.0.3239.18.KO.PNG 24.0 KB

	chrome.63.0.3239.18.KO.PNG 24.0 KB View Download

Already added this issue before: https://bugs.chromium.org/p/chromium/issues/detail?id=778581

For some reason my issue was set to WontFix without any explanation.
As some people already suggested this feature is important when using AJAX requests in any framework. All the errors are given as an HTML page, which is not parsed in the preview tab anymore. It just shows the same as the response tab.

Last time this was working correctly was in chrome 60.0.3112.78

 Issue 778581  has been merged into this issue.

 Issue 789154  has been merged into this issue.

 Issue 795335  has been merged into this issue.

Our goal was to only display HTML in the error responses to XHR requests. At one point this got broken so I will be fixing it. There are no plans to preview HTML resources there as the Preview panel was never meant to be a full browser. It should not be fetching other resources (scripts, style sheets, images), execute JavaScript code and such.

eostroukhov@chromium.org, to be honest, we are not demanding anything extra than to have something we had at point of 60.0.3112.78 ver, it is super useful and thank you for implementing it in the first place.

There was a bug at some point when HTML was always previewed as HTML, not just for the errors. That was a regression...

it is super useful when you can use tools as symfony var-dumper for purpuses of debugging, sort of like console.log in js

I agree. I use the symfony dump function a lot on xhr requests to see debug information. Now I have to convert the raw dump to HTML preview myself. Wasn't like that in v60.

Rendering the HTML is a very helpful feature. Most framework debugging tools (Laravel, Symfony, etc.) are currently impossible to use in Chrome, forcing me to seek out other browsers for development. With the removal of this and the recent removal of allowing a user to proceed to a site lacking SSL certificates, Chrome is quickly losing it's appeal as a development tool.

For now our team has made at wrapper around debugger functions that sets the statuscode of the response to 500, this will make chrome render HTML and load resources.

Not having the preview has been incredibly frustrating these last few months, any progress on fixing this regression?

I agree, the past few months without this feature has been frustrating. Please restore this behavior.

HTML preview is working for XHR errors.

There is no plan to preview HTML for resources in other cases.

In case it helps someone, Firefox 59 (currently the beta, due for release in March) has this feature. They also removed it without warning but thankfully decided to put it back in as of V59. I don't think it's quite as slick as Chrome but if you're stuck with HTML errors being returned via XHR requests then it might be worth a look, as remaining on v60 indefinitely isn't a viable solution going forward. 

Yes I suggest everyone move over to Firefox to resolve the issue as obviously Chrome has zero intention of reinstating a feature that was working. In fact Chrome is starting to become too widespread and they are starting to veer off conventions and standards set by the W3C to push their own agenda.

It looks like they became so powerful that now they are totally ignorant to what is comfortable for developers, even though for them it's just a tiny code change to allow render off HTML as it used to be in that panel. Really annoying. This is just stupid as dev tools specifically created for developers.

>> HTML preview is working for XHR errors.
WHERE? It's not working non for errors, non for non-errors.

Having looked through the many Product Forum posts about this issue and specifically in reply to comment 14 about the panel fetching other resources, I personally haven't really seen anyone asking for this tab to be a full on browser in it's own right. We just need it to render any inline resources which are returned to it, rather than dumping them out as source.

I can only speak for the Laravel error pages but the resources there are self contained. Other frameworks you would presume expect their errors to be returned to Developers who don't always have a network connection. So you'd hope the good ones aren't trying to access external resources. If they are then that could well be addressed within the framework.

Further to this issue it seems that Google/Chrome added this feature 7 years ago to solve the same problem then as everyone is having now.(https://bugs.chromium.org/p/chromium/issues/detail?id=48389 and https://bugs.webkit.org/show_bug.cgi?id=58886) 

I don't think any of us can really understand why something which was added as a feature 7 years ago, which we've all been using for years, is now out of the blue considered a bug? The irony being that 7 years ago there were probably only a very limited number of Devs needing that particular feature. However in 2018 the ubiquitous nature of frameworks and our reliance on receiving data via XHR requests means that a great deal more of us are doing this, whether we like it or not. One day it'll perhaps die out but we're not there yet!

Maybe the panel needed some tweaking, perhaps blocking external resources from being loaded would have been a good place to start. I don't know if that would have been a problem for others as I'm not privy to every framework or workflow out there but it sounds reasonable, based on my assumption above about framework error pages. Completely removing it's ability to render however, along with a stonewall refusal to reconsider definitely seems like an unreasonable move to me. 

As it is, as we approach 5 months of this issue and with it once again being labelled as a 'WontFix' I guess it's best not to hold your breath that at some point Google/Chrome will follow Mozilla/Firefox's lead and see fit to reinstate this 'bug' (which used to be a feature)!

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

commit 0a9c4fe31451a99109ffb695fcb4085fd8e7e72f
Author: Eugene Ostroukhov <eostroukhov@chromium.org>
Date: Thu Feb 01 17:25:54 2018

DevTools: restore HTML preview

Network panel will now preview all HTML responses.

Bug:  785050 
Change-Id: I79b3c22300a4f132bf1b3e4842c06f291249a09d
Reviewed-on: https://chromium-review.googlesource.com/896367
Commit-Queue: Eugene Ostroukhov <eostroukhov@chromium.org>
Reviewed-by: Pavel Feldman <pfeldman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#533711}
[modify] https://crrev.com/0a9c4fe31451a99109ffb695fcb4085fd8e7e72f/third_party/WebKit/LayoutTests/http/tests/devtools/network/network-choose-preview-view-expected.txt
[modify] https://crrev.com/0a9c4fe31451a99109ffb695fcb4085fd8e7e72f/third_party/WebKit/LayoutTests/http/tests/devtools/network/preview-searchable-expected.txt
[modify] https://crrev.com/0a9c4fe31451a99109ffb695fcb4085fd8e7e72f/third_party/WebKit/Source/devtools/front_end/network/RequestPreviewView.js
[modify] https://crrev.com/0a9c4fe31451a99109ffb695fcb4085fd8e7e72f/third_party/WebKit/Source/devtools/front_end/network/ResourceWebSocketFrameView.js
[modify] https://crrev.com/0a9c4fe31451a99109ffb695fcb4085fd8e7e72f/third_party/WebKit/Source/devtools/front_end/source_frame/JSONView.js
[modify] https://crrev.com/0a9c4fe31451a99109ffb695fcb4085fd8e7e72f/third_party/WebKit/Source/devtools/front_end/source_frame/PreviewFactory.js

Preview should now always render HTML contents. Well, except when said contents is a JSON string. Then it should be object rendering.

Big thanks for fixing, is great news and much appreciated!

 Issue 809007  has been merged into this issue.

Your change meets the bar and is auto-approved for M65. Please go ahead and merge the CL to branch 3325 manually. Please contact milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

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

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

commit 5ef332c3a49a8839b2c9103f8375b398fdd051d7
Author: Eugene Ostroukhov <eostroukhov@chromium.org>
Date: Tue Feb 06 23:12:08 2018

DevTools: restore HTML preview

Network panel will now preview all HTML responses.

TBR=eostroukhov@chromium.org

(cherry picked from commit 0a9c4fe31451a99109ffb695fcb4085fd8e7e72f)

Bug:  785050 
Change-Id: I79b3c22300a4f132bf1b3e4842c06f291249a09d
Reviewed-on: https://chromium-review.googlesource.com/896367
Commit-Queue: Eugene Ostroukhov <eostroukhov@chromium.org>
Reviewed-by: Pavel Feldman <pfeldman@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#533711}
Reviewed-on: https://chromium-review.googlesource.com/905623
Reviewed-by: Eugene Ostroukhov <eostroukhov@chromium.org>
Cr-Commit-Position: refs/branch-heads/3325@{#355}
Cr-Branched-From: bc084a8b5afa3744a74927344e304c02ae54189f-refs/heads/master@{#530369}
[modify] https://crrev.com/5ef332c3a49a8839b2c9103f8375b398fdd051d7/third_party/WebKit/LayoutTests/http/tests/devtools/network/network-choose-preview-view-expected.txt
[modify] https://crrev.com/5ef332c3a49a8839b2c9103f8375b398fdd051d7/third_party/WebKit/LayoutTests/http/tests/devtools/network/preview-searchable-expected.txt
[modify] https://crrev.com/5ef332c3a49a8839b2c9103f8375b398fdd051d7/third_party/WebKit/Source/devtools/front_end/network/RequestPreviewView.js
[modify] https://crrev.com/5ef332c3a49a8839b2c9103f8375b398fdd051d7/third_party/WebKit/Source/devtools/front_end/network/ResourceWebSocketFrameView.js
[modify] https://crrev.com/5ef332c3a49a8839b2c9103f8375b398fdd051d7/third_party/WebKit/Source/devtools/front_end/source_frame/JSONView.js
[modify] https://crrev.com/5ef332c3a49a8839b2c9103f8375b398fdd051d7/third_party/WebKit/Source/devtools/front_end/source_frame/PreviewFactory.js