1895024 - Large images truncated in ResponsePanel.js do not warn that the response body is truncated

Status: NEW

(DevTools :: Netmonitor, defect, P3)

Description

[gliu20]

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

Steps to reproduce:

STR:

1. Create a website that loads an image that is greater than 1MiB (devtools.netmonitor.responseBodyLimit > 1048576)
2. Open Devtools Network Monitor
3. Open website that fetches an image and inspect the request

Actual results:

The image preview on hover is truncated
The image preview in ImagePreview.js (sidepanel) is truncated

Issue:
No message about truncated response body

Expected results:

A message indicating that the response body has been truncated

Comment 1

[gliu20]

Possible Cause

We never reach line 462 where the Truncated Message error is displayed

https://searchfox.org/mozilla-central/source/devtools/client/netmonitor/src/components/request-details/ResponsePanel.js#462

      error && div({ className: "response-error-header", title: error }, error),

...since we skip that line and just directly render an ImagePreview component

https://searchfox.org/mozilla-central/source/devtools/client/netmonitor/src/components/request-details/ResponsePanel.js#436

    if (Filters.images({ mimeType })) {
      return ImagePreview({ encoding, mimeType, text, url });
    }

The ImagePreview component expects an un-truncated input but the prop encoding appears to be truncated.

https://searchfox.org/mozilla-central/source/devtools/client/netmonitor/src/components/previews/ImagePreview.js

Expected behaviour

The question is what would the expected behaviour be? I'm currently thinking of two different behaviours:

1. ImagePreview should receiving the non-truncated data and thus not need to display error messages (as what the current implementation seems to assume)
2. ImagePreview should use the truncated data and thus should simply display an error message

I'm currently leaning towards option 2.

Comment 2

[Julian Descottes [:jdescottes]]

Thanks for the detailed report. It will be technically difficult to implement the option 1, so we should probably do option 2 and show an error message in this case.

Comment 3

[gliu20]

Awesome sounds good! I'd be open to submitting a patch if no one else is working on this

Comment 4

[Hubert Boma Manilla (:bomsy) PTO until Sept 1st]

Sure go ahead!