Network preview no longer renders html

[l...@conferencemanager.dk]

After updating from version 61 to 62 the network preview tab no longer renders html.

I see that a JSON issue regarding preview has been solved in 63, but can't seem to find anything about this issue.

Response headers before:

Preview before:

Response headers after:

Preview after:

[Kayce Basques]

Hmm I think the "before" behavior was a bug. The Preview tab usually shows the HTML source content.

[PhistucK]

But, then, what is the difference between "Response" and "Preview" for HTML? It makes "Preview" redundant if it just a copy of "Response". It should render HTML like it always had.

And it is weird, because you recently fixed that HTML-is-rendered-as-one-line regression and I thought you fixed it by rendering it correctly, not by not rendering it at all...

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "Google Chrome Developer Tools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-chrome-developer-tools+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-chrome-developer-tools/5cc63299-f683-4ca5-8ad5-70c347d5c189%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Kayce Basques]

Good point. I forgot about the Response tab.

Yeah, makes more sense that Preview would show rendered HTML. So maybe it's a regression.

Aside: IMO Preview tab just doesn't make much sense in some scenarios. Isn't rendered HTML just... the viewport?

On Tuesday, November 14, 2017 at 3:54:01 AM UTC-8, l...@conferencemanager.dk wrote:

[PhistucK]

It shows raw structure, or it can show formatted debugging information. It can be helpful sometimes.

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "Google Chrome Developer Tools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-chrome-developer-tools+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-chrome-developer-tools/b63b654f-c279-4298-aa81-7de1971c562c%40googlegroups.com.

[Mark]

For me being able to see the rendered output of errors from a framework such as Laravel when doing AJAX requests is essential. Up until Chrome 61 I was happily doing that but with Chrome 62 it's almost impossible to work this way now without a fully rendering Preview pane. The alternative is to copy and paste into a code editor and render, which is killing productivity for me.

What's crazy is that Firefox appear to have broken or removed their Preview pane in their Dev Tools at the same time! Thankfully the nightly build of Firefox 59 has just added this feature back in. So that might be useful for anyone that needs this until Chrome sort it out.

An additional bonus, seemingly for me anyway, is that the new FF57 (and thus FF59) is currently using a hell of a lot less RAM when being run with a lot of tabs open in Ubuntu 16.04.

[Kayce Basques]

You all are in a better position than me to know how it behaved in the past and what's useful in general. By all means file a bug if you're seeing regressions!

https://crbug.com

[Patompong Savaengsuk]

Thanks for pointed this out. I use Laravel for 2 years and was really happy with Chrome and HTML in the network preview tab. I just notice this now since I was working on Go project. Now I tested FF59 and it's really render the HTML. Thank you :)

[Vael Victus]

Can confirm it's still happening as of Chrome 63.

[Chris Jolley]

Driving me crazy too, this. Chrome 63, mac.. 
Going to have to roll back to 61 by the look of it! ridiculous state of affairs!
Has a bug already been filed?

[Sunil Boodram]

Yep, this is a bit annoying.

A ticket for this has already been opened.  If anyone is interested here's the link: 

https://bugs.chromium.org/p/chromium/issues/detail?id=785050

[Kayce Basques]

So, it sounds like you want the Preview tab to render HTML. In the issue that Sunil linked to, a DevTools engineer said that that behavior was unintentional.

As a workaround, can you just load the HTML resource in a new tab? 

[Kayce Basques]

This other thread (now locked) was also discussing the topic:

https://groups.google.com/forum/#!topic/google-chrome-developer-tools/9cEpej36YKE

On Tuesday, November 14, 2017 at 3:54:01 AM UTC-8, l...@conferencemanager.dk wrote:

[ase...@celerant.com]

Has anyone found a solution/workaround to get this to work? I'm having to copy the HTML and render it elsewhere... huge lost of productivity. 

[wyxa]

Chrome 64 — same issue, same behavior. 

For GET ajax requests, right-click and pick «Open in new tab» works good - at least no need to copy the HTML to render.

For POST ajax-requests it is crazy :-(((

Any work around or Chrome plugin anyone can recommend?

[da...@davidvaleo.com]

I have had some success changing the status code on the response, it seems that if its something other than 200 chrome will try to render the preview. I have been setting the status code to 500 when debugging.

[TrubOn ru]

HEY Guys, Seems like in v66 of unstable chanell this bug has been fixed! OMG i`m soooooooooo happy! 

среда, 31 января 2018 г., 23:16:28 UTC+5 пользователь da...@davidvaleo.com написал:

[Mike Zheng]

Yeah, I tried Chrome Canary Version just now and it proved to have solved this problem, however in Chrome stable version, the problem still exists :)

[Kayce Basques]

The team listened to your feedback (here, and on crbug.com) and changed the behavior to match what you want.

In Chrome 66, the Preview tab now always renders a preview of the HTML content.

Chrome 66 will hit Stable around 2018 April 17. Download Chrome Canary in the meantime in order to access this feature.

[Loami Santos Franca]

Chrome Canary ins't available for linux users, the beta version (66.0.3359.33) is rendering...

https://www.google.com/chrome/browser/beta.html

[Dan Schumann]

Mine is 500 and still renders html source rather than html

1. cache-control:
   no-cache, private
2. content-type:
   text/html; charset=UTF-8
3. date:
   Thu, 31 Jan 2019 15:51:16 GMT
4. server:
   nginx/1.11.8
5. status:
   500

[Dan Schumann]

Still doing this for me.. It's so annoying because laravel errors are much harder to read as html source.

[Joey Arhar]

I’m surprised that it doesnt render html. If its easy to replicate, could you file a bug with the component Platform>DevTools>Network?

[Patompong Savaengsuk]

Now it's worst for Laravel. If you dd() an array or object it will just show blank (nothing) in the Preview tab.

[mshoe...@gmail.com]

New issue opened: https://crbug.com/930061

[Willy Setiawan]

You can double clicked the request name, it will open a new tab and renders the html. its work for me.

[Bryan McNeil]

This is also happening when trying to render a <font> tag. If I do a var_dump in php and view it in the network preview pane it will stop rendering at the start of the <font> tag and anything beyond that is not rendered at all.

[Joey Arhar]

I fixed the new issue which was due to the '#' character not being escaped in the data url of the iframe of the request preview view. It sounds like <font> tags could have #s in them, which could be the same problem. Can you reproduce on Canary?

[Bryan McNeil]

I downloaded Version 74.0.3718.0 (Official Build) canary (64-bit) and it looks good there. I'm able to do var_dump's without the preview breaking on the <font> tags. Thanks!

[Ozan Kurt]

Latest version, still doesn't work.

[hu...@media-cnc.com]

same problem , please help

[Joey Arhar]

I submitted a fix which will be live in version 73, which is already being rolled out. If you are still having issues due to being on version 72, try the beta, dev, or canary channels.

[goo...@e-nexus.de]

Fixed in Version 73.0.3683.86 (Offizieller Build) (64-Bit)