Fixed

Bug

Status Update

No update yet.

Description

ch...@google.com

created issue on behalf of da...@gmail.com #1

Sep 26, 2024 11:30AM

Steps to reproduce the problem

Open a new tab
Open dev tools for that tab
Navigate to https://tinyurl.com/bdd48nan
Check the network traffic (xhr) and look for any call to "monolith" (https://ext-qa-gameforfun.thunderkick.com/monolith)
Mark the call and inspect the preview and response tabs (note also status code 200, success)

Problem Description

Expected results: The preview should show the response as JSON (which it is) The response tab should show the response

Actual results: Preview window says "Preview not available" Response window says "This request has no response data available"

Additional Comments

We have identified that the issue first appeared in Chrome 129. It is not present in Chrome 128.

Summary

Chrome Network tab doesn't display response (preview nor actual response) properly.

Additional Data

Category: Developer Tools
Chrome Channel: Stable
Regression: Yes

chrome_129_variations.txt

45 KB

View

Download

Comments

pe...@google.com <pe...@google.com> #2Sep 26, 2024 11:44AM

All Chrome DevTools regression bugs must be P0 or P1. Changing this bug to P1 because it is marked as a regression. See go/chrome-devtools/regressions for details about the process. This issue was identified as a Chrome DevTools regression. Forwarding to Chrome DevTools triage by removing it from the Unconfirmed hotlist. See go/chrome-devtools/regressions for details about the process.

da...@gmail.com <da...@gmail.com> #3Sep 26, 2024 12:55PM

Issue is limited to Chromium based browsers (Chrome, Edge) but not to other vendors such as FireFox or Opera.

ja...@google.com <ja...@google.com> #4Sep 26, 2024 07:23PM

ya...@google.com <ya...@google.com> Sep 27, 2024 05:27AM

Status: Duplicate of

369748448

sz...@google.com <sz...@google.com> #5Sep 27, 2024 05:45AM

Status: Assigned (reopened)

The reported Content-Type for "monolith" requests is application/octet-stream which indicates arbitrary binary data. But it also includes a charset=utf-8 so it's somewhat confusing. DevTools doesn't think that application/octet-stream is text content so we don't attempt to decode it. Maybe we need to re-think this heuristic.

da...@gmail.com <da...@gmail.com> #6Sep 27, 2024 06:56AM

"The reported Content-Type for "monolith" requests is application/octet-stream which indicates arbitrary binary data. But it also includes a charset=utf-8 so it's somewhat confusing. DevTools doesn't think that application/octet-stream is text content so we don't attempt to decode it. Maybe we need to re-think this heuristic."

That may be something new then as Chrome did decode it in earlier versions (as evident by the regression). What is the intended behaviour?

sz...@google.com <sz...@google.com> #7Sep 27, 2024 07:03AM

See the CL description here: https://crrev.com/c/5895184. We made DevTools a bit more cautious about decoding arbitrary binary data, as we would show wrong things e.g. when not properly decoding utf-8 or utf-16. We don't have a lot to go on other than the Content-Type but it seems that a lot of web apps/frameworks/services use binary or custom media types but send text content over it.

The fix in https://crrev.com/c/5895184 also fixes this bug, as the backend already decoded the payload and DevTools gets it as text already. Apologies for any inconvenience caused. I'll try to get the fixes back-merged to 130. FWIW I think in this case a Content-Type of text/plain might be more appropriate or one that describes the actual text format used.

ap...@google.com <ap...@google.com> #8Sep 27, 2024 07:44AM

Project: devtools/devtools-frontend
Branch: main
Author: Simon Zünd <szuend@chromium.org>
Link: https://chromium-review.googlesource.com/5895184

[network] Fix ContentData.isTextContent being too restrictive

Expand for full commit details

[network] Fix ContentData.isTextContent being too restrictive

This CL fixes a major regression for Network "Preview" and "Response"
tab. ContentData was initially too restrictive in what it considers
text content. It only checked the `Content-Type` (media type) header,
so we don't accidentally decode arbitrary binary data.

But the backend might have already set us text content. Given that
a lot of web apps do odd things with `Content-Type` we should really
just show text content when we have it.

Bug: 369369574,369748448,369756813,369931288
Change-Id: If51991bb66aa2f54a8f2e1b8ca46ec308622511b
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/5895184
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>

Files:

M front_end/models/text_utils/ContentData.test.ts
M front_end/models/text_utils/ContentData.ts
M front_end/models/text_utils/StreamingContentData.ts

Hash: e940f678425b74bb33c424f03270fa771d9bc2b8
Date: Fri Sep 27 09:12:05 2024

ap...@google.com <ap...@google.com> #9Oct 1, 2024 07:36AM

Project: devtools/devtools-frontend
Branch: chromium/6723
Author: Simon Zünd <szuend@chromium.org>
Link: https://chromium-review.googlesource.com/5899736

[network] Fix ContentData.isTextContent being too restrictive

Expand for full commit details

[network] Fix ContentData.isTextContent being too restrictive

This CL fixes a major regression for Network "Preview" and "Response"
tab. ContentData was initially too restrictive in what it considers
text content. It only checked the `Content-Type` (media type) header,
so we don't accidentally decode arbitrary binary data.

But the backend might have already set us text content. Given that
a lot of web apps do odd things with `Content-Type` we should really
just show text content when we have it.

Bug: 369369574,369748448,369756813,369931288
Change-Id: If51991bb66aa2f54a8f2e1b8ca46ec308622511b
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/5895184
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
(cherry picked from commit e940f678425b74bb33c424f03270fa771d9bc2b8)
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/5899736
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>

Files:

M front_end/models/text_utils/ContentData.test.ts
M front_end/models/text_utils/ContentData.ts
M front_end/models/text_utils/StreamingContentData.ts

Hash: 1480199e7c61b7721c6acb49979dbb00fe63a62e
Date: Fri Sep 27 09:12:05 2024

sz...@google.com <sz...@google.com> Oct 18, 2024 08:25AM

Marked as fixed.

da...@gmail.com <da...@gmail.com> #10Oct 18, 2024 09:29AM

Thanks! Works like a charm!

js...@google.com <js...@google.com> #11Oct 21, 2024 10:35AM

Verified the fix on Latest Chrome Canary #132.0.6789.0 using Windows

Observed that the preview and response is showing the data

Please refer to the attached screenshot below:

The fix is working as expected,adding the below milestone and build Number in Verified In field.

132.0.6789.0,132

Thanks..!!

Message last modified on Oct 30, 2024 05:06PM

CL Preview and response.mp4

35 MB

Download

pe...@google.com <pe...@google.com> #12Oct 29, 2024 03:36PM

All Chrome DevTools regression bugs must be verified and the milestones in which these where found and verified must be recorded in the Found In and Verified In fields respectively. This issue was closed as Fixed but doesn't have milestone information in the Found In and Verified In fields. Please verify that the issue is fixed and record the milestones in the Found In and Verified In fields. See go/chrome-devtools/regressions for details about the process.

Thanks for your time! To disable nags, add Disable-Nags (case sensitive) to the Chromium Labels custom field.

jo...@gmail.com <jo...@gmail.com> #13Oct 30, 2024 03:43PM

i took a look at chrome 132 beta, theres still some major differences between that and chrome 128 for the network tab.
binary data like .ts segements gets rendered in some table and loses focus of the network requests columns.

also some m3u8/mpds video requests still dont render well. is it possible to revert this to chrome 128 network tab rendering?

hu...@gmail.com <hu...@gmail.com> #14Oct 30, 2024 03:51PM

You can check

issue 369369574

for some more discussions about this, especially about m3u8.

sz...@google.com mentioned they are going to fix/improve this further in near future, which is very appreciated.

But as I said there, the devs should leave at least one issue ticket open *now* (preferably with a clearer title) to track this ongoing issue instead of duplicating them around despite the fact the issues are still there.

Not sure why nothing has been done in this regard (to have an open ticket) in the last few days, despite people constantly open new tickets about the same issue.

jo...@gmail.com <jo...@gmail.com> #15Oct 30, 2024 03:56PM

yeah having an option to revert to what they did in chrome 128 seems better to try decode everything as text seems better.

sz...@google.com <sz...@google.com> #16Oct 31, 2024 06:56AM

The tracking bug for having a mix of old/new behavior is in issue 375546679. It landed yesterday so should be available with Chrome Canary (132) tomorrow. Now you'll be able to view binary content either as base64, the hex view or force utf-8 decode it. The selected option should persist across DevTools sessions, so if you select "utf-8" and it should now basically work as in Chrome 128.

Apologies again for breaking the workflows here.

pe...@google.com <pe...@google.com> #17Nov 13, 2024 03:37PM