1710573 - Firefox inserts ellipsis in jwt strings headers in network tab in developer tools

Status: RESOLVED DUPLICATE of bug 1696128

(DevTools :: Netmonitor, defect, P3)

Description

[erik.itland]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0

Steps to reproduce:

1. I opened a web application that I am working on
2. I quickly opened the developer tools to capture network traffic during loading
3. I click on a request that is sent with Bearer token and copy the token
4. I try to reuse the token in Postman, then try to verify it on jwt.io.
5. I try on the same website running in another environment. It doesn't work there either.
6. I try using chrome.

Actual results:

The token that i copied didn't work.

Upon a quick examination I discovered for instance that three consecutive dots in one case were replaced with ellipsis.

The same token - when copied in the same way from Chrome - just works.

Expected results:

It should have worked also when I copied it from Firefox. It used to work and I have used it a number of times before, including on this project.

Comment 1

[erik.itland]

Update: It probably isn't a formatting problem but rather that Firefox has cut some of the string and replaced it with ellipsis.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'DevTools::Netmonitor' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 3

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Thank you for the report!

Any chance to get a test page we could use to reproduce the problem on our machines?
Also, where/how exactly are you copying the token?
Can you please provide more instructions and/or a screenshot?

Thank you!

Comment 4

[erik.itland]

Hi and thanks for getting back so quickly! This happened in an internal system so I went ahead and try to find something easily reproducible on the general internet and I think I have succeeded:

I've found two more useful bits of information:

1. It also happens in cookie information, you can probably recreate this easily by going to bing or google home page as a logged in user and look at the Cookie: line in most of the requests. In both cases (bing and google) the ellipsis shows up in column 513 according to IntelliJ (I copied both to a scratch buffer to verify). Furthermore, both are exactly 1024 characters long which further supports that it has been truncated

FTR: I tried in both of these with a logged out users and the cookies size then wasn't big enough to trigger it it seems.

2. While I was at it I did a web search for ellipsis in headers firefox on duckduckgo (https://duckduckgo.com/?t=ffab&q=elipsis+in+headers+firefox&ia=web) and I found this case here https://bugzilla.mozilla.org/show_bug.cgi?id=1631230

I see you worked on that as well. Is it possible that this case is a regression of the one that Mozilla fixed a year ago?

To me it looks very similar, only that time the headers were more heavily truncated.

Comment 5

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Attachment: image.png

Thank you for the update.

I can reproduce the problem on my machine, see the attached screenshot.

We've been fixing this in bug 1631230, by removing the limit in this patch:
https://phabricator.services.mozilla.com/D75688

We could pass cropLimit: -1, instead of removing it entirely, which would force the logic to not do any cropping. But, I think that it would be better to keep the default limit (1024) and make sure to copy the original value (not the cropped one) when using the context menu copy action.

Honza

Comment 6

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Here is the copy function used to copy the clicked item value into the clipboard
https://searchfox.org/mozilla-central/rev/6e630edb09c3ab06d0103665b16c9ea7dce782c5/devtools/client/netmonitor/src/widgets/PropertiesViewContextMenu.js#89-107

Comment 7

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Some comments:

1. We could change the copy method implementation (see the link above) and instead of copying the selection, we could access the original value through the member argument passed into the function

2. We should use the HeadersProvider to get the label using getLabel from the member
   https://searchfox.org/mozilla-central/rev/6e630edb09c3ab06d0103665b16c9ea7dce782c5/devtools/client/netmonitor/src/utils/headers-provider.js#41

A provider is used to populate the tree widget used to render all the HTTP headers. And getLabel is used to get the original string for the UI, which is consequently (in the UI) cropped when rendered.

3. The pointer to the current provider could be passed in the same way as contextMenuFormatters
   https://searchfox.org/mozilla-central/rev/6e630edb09c3ab06d0103665b16c9ea7dce782c5/devtools/client/netmonitor/src/components/request-details/PropertiesView.js#162

this.contextMenu = new PropertiesViewContextMenu({
  customFormatters: this.props.contextMenuFormatters,
  provider: this.props.provider,
});

4. Note that the copy method is duplicated here:
   https://searchfox.org/mozilla-central/rev/6e630edb09c3ab06d0103665b16c9ea7dce782c5/devtools/client/netmonitor/src/widgets/HeadersPanelContextMenu.js#108

Honza

Comment 8

[Jan Honza Odvarko [:Honza] (always need-info? me)]

@bomsy: this could be first good bug, WDYT?

Comment 9

[Hubert Boma Manilla (:bomsy)]

Yeah.
It seems like an easy fix, but might also require some time to understand the context menu for-matters, to actually fix.

Comment 10

[Angelina]

Hello, could you assign it to me?

Comment 11

[Angelina]

(In reply to Hubert Boma Manilla (:bomsy) from comment #9)

Yeah.
It seems like an easy fix, but might also require some time to understand the context menu for-matters, to actually fix.

Sorry, didnt mention you in the previous message. Could you assign this bug to me?

Comment 12

[Jan Honza Odvarko [:Honza] (always need-info? me)]

See also: Bug 1696128 - The Authorization header is cropped in NetworkMonitor for long JWT tokens.

The decision in that bug is to disable cropping for Headers.
So, to be consistent we should do the same for Cookies.

Bomsy, WDYT?

Honza

Comment 13

[Hubert Boma Manilla (:bomsy)]

(In reply to Jan Honza Odvarko [:Honza] (always need-info? me) from comment #12)

See also: Bug 1696128 - The Authorization header is cropped in NetworkMonitor for long JWT tokens.

The decision in that bug is to disable cropping for Headers.
So, to be consistent we should do the same for Cookies.

Bomsy, WDYT?

Yes i agree! let's be consistent everywhere.

Comment 14

[Jan Honza Odvarko [:Honza] (always need-info? me)]

(In reply to Angelina from comment #10)

Hello, could you assign it to me?

Assigned to you, thank you for helping

Comment 15

[Angelina]

(In reply to Jan Honza Odvarko [:Honza] (always need-info? me) from comment #12)

See also: Bug 1696128 - The Authorization header is cropped in NetworkMonitor for long JWT tokens.

The decision in that bug is to disable cropping for Headers.
So, to be consistent we should do the same for Cookies.

Bomsy, WDYT?

Honza

Hello! I am a little bit confused.
Since the last patch in that bug -https://bugzilla.mozilla.org/show_bug.cgi?id=1696128 seems to fix the problem with the Cookie line cropping in the Headers panel :)
So it means my bug is fixed or should I disable cropping in the Cookie panel too?

Comment 16

[Jan Honza Odvarko [:Honza] (always need-info? me)]

(In reply to Angelina from comment #15)

Hello! I am a little bit confused.
Since the last patch in that bug -https://bugzilla.mozilla.org/show_bug.cgi?id=1696128 seems to fix the problem with the Cookie line cropping in the Headers panel :)
So it means my bug is fixed or should I disable cropping in the Cookie panel too?

Ah, you are right, this bug is a duplicate of bug 1696128
I'll close it in favor of that bug

Honza