feat(trace-viewer): display text attachments in ui mode

[alvaromartmart]

Closes #30976

Displays text attachment contents in UI mode

[dgozman]

@alvaromartmart Thank you for the PR! We discussed this with the team, and came up with a few comments/suggestions:

• Could you please attach a screenshot that illustrates the UI implemented in the latest commit?
• We feel like the proposed UI is not very intuitive and we could bring more clarity and structure into it. Perhaps we can show no preview available for other attachments when there is at least a single preview? Otherwise the UI looks confusing to me.
• Looking at the code, multi-line attachments will be rendered as a single line.
• Perhaps we should make this more like network request/response body preview? See here for the code pointer.
• In addition to text/plain, we can preview many more textual mime types.

[alvaromartmart]

@alvaromartmart Thank you for the PR! We discussed this with the team, and came up with a few comments/suggestions:

Thank you for the feedback!

• Could you please attach a screenshot that illustrates the UI implemented in the latest commit?

Here's a (WIP) screenshot with some annotations (more on them below)

• We feel like the proposed UI is not very intuitive and we could bring more clarity and structure into it. Perhaps we can show no preview available for other attachments when there is at least a single preview? Otherwise the UI looks confusing to me.

Agree on the "no preview available". Additionally, I was wondering whether we should

1. Add some hr dividers between attachment to clearly tell them apart
2. Since attachments could be potentially big and the user not always be interested in looking at them, should we
   2.a. render them by default
   2.b. use an expansion panel, requiring user to expand them to see the contents
   2.c. render by default files below some size threshold, otherwise use expansion panel

• Looking at the code, multi-line attachments will be rendered as a single line.

They seem to render just fine, do you have a specific edge case in mind?

• Perhaps we should make this more like network request/response body preview? See here for the code pointer.
• In addition to text/plain, we can preview many more textual mime types.

The screenshot above is the result of some experimentation using the CodeMirrorWrapper as you suggested. However I have some questions if we go this way:

3. should we infer when possible the language based on the mimeType to get the most accurate syntax highlighting?
4. should we always render as plain text, leveraging the styling of the CodeMirrorWrapper but skipping language-specific stuff?
5. attachments are displayed based on the isTextualMimeType utility now, but that utility includes image/svg - some users might expect the svg to be rendered instead of its source. Though this is likely an edge case that could be covered as a future iteration 😅

[pavelfeldman]

All good questions - the lack of definitive answers to those is the exact reason we did not rush into implementing it. If you have a good idea on reasonable defaults, include those in the PR and we'll be happy to take a look.

[alvaromartmart]

Ok so in 0eb57e7 I placed the attachment in an expansion panel. You can see a demo here

Screen.Recording.2024-06-25.at.23.21.58.mov

This way:

• attachments can still be downloaded as previously by clicking on their name
• attachments are not rendered by default, user needs to expand the panel
  • we could add an opt-in setting to expand attachments by default, but I guess it would be useful to collect user feedback first? Also I don't know if there are already ui mode specific settings

As for the CodeMirrorWrapper questions I posted here earlier, and to avoid scope creep, I decided to keep things simple and just render the raw content without trying to infer language / display svg as images. I think that can be done if needed in a future PR, if users ask for it.

Final question: since it's now using an expansion panel, maybe I can get rid of the <hr> delimiters, WDYT?

[alvaromartmart]

ugh, forgot to update the tests - tomorrow

[pavelfeldman]

Your change looks good. I have a code suggestion inline and a UX suggestion below:

• Expandable title should not click away, the entire title should be a click target for expand, that would make it a better UX
• You can have a download icon next to it to allow downloading, both in expanded and collapsed state

[pavelfeldman]

Instead of this, I wonder if we should change the <Expandable> contract to be

<Expandable expanded={} body={() => <TextAttachment/>}>

We don't seem to have any usages of it yet, so easy to change.

[alvaromartmart]

Instead of this, I wonder if we should change the contract to be

<Expandable expanded={} body={() => <TextAttachment/>}>

Not a React expert but I'm not sure I really like this change in contract vs. directly "projecting" the body into the Expandable component.

We don't seem to have any usages of it yet, so easy to change.

The Expandable was already used here, though it doesn't rely on the body, it seems it's only used to toggle the state.

All things considered, I can apply the change if you want as it seems quite straightforward one. Just not sure it's worth it. WDYT?

[pavelfeldman]

It would look better than the manual isMounted management to me!

[alvaromartmart]

Got rid of the isMounted as part of #31215 (comment), but I'm not sure if your request here is still relevant.

On a different note, I wonder if at this point I should merge ExpandableAttachment and TextAttachment into a single component for simplicity. Please LMKWYT

[alvaromartmart]

Your change looks good. I have a code suggestion inline and a UX suggestion below:

• Expandable title should not click away, the entire title should be a click target for expand, that would make it a better UX
• You can have a download icon next to it to allow downloading, both in expanded and collapsed state

Done, thanks for the feedback: 700d061

Demo:

Screen.Recording.2024-06-28.at.23.16.05.mov

[alvaromartmart]

In 677ecae I slightly simplified & improved the ExpandableAttachment and TextAttachment implementation so that the attachments are only fetched once and only after the panel is expanded for the first time. This seems more efficient than fetching every time as the contents won't change.

[github-actions]

Test results for "tests 1"

8 flaky

⚠️ [chromium-library] › library/browsercontext-fetch-happy-eyeballs.spec.ts:49:3 › get should work on request fixture
⚠️ [chromium-library] › library/browsercontext-fetch-happy-eyeballs.spec.ts:49:3 › get should work on request fixture
⚠️ [chromium-library] › library/browsercontext-fetch-happy-eyeballs.spec.ts:49:3 › get should work on request fixture
⚠️ [firefox-library] › library/browsercontext-fetch-happy-eyeballs.spec.ts:49:3 › get should work on request fixture
⚠️ [firefox-page] › page/page-event-request.spec.ts:169:3 › should return response body when Cross-Origin-Opener-Policy is set
⚠️ [chromium-library] › library/browsercontext-fetch-happy-eyeballs.spec.ts:49:3 › get should work on request fixture
⚠️ [playwright-test] › ui-mode-test-screencast.spec.ts:21:5 › should show screenshots
⚠️ [webkit-library] › library/browsercontext-fetch-happy-eyeballs.spec.ts:49:3 › get should work on request fixture

28408 passed, 655 skipped
✔️✔️✔️

Merge workflow run.