1745416 - Remove old code related to the old new request panel

Status: ASSIGNED

(DevTools :: Netmonitor, task, P3)

Description

[Claudia Batista [:claubatista]]

Entire codebase related to the old panel and not reused should be removed.

Comment 1

[Claudia Batista [:claubatista]]

Attachment: Bug 1745416 - [devtools] Remove old code related to the old new request panel r=bomsy

Comment 2

[BugBot [:suhaib / :marco]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Comment 3

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

Bomsy, how far we are from landing this?

Comment 4

[Suhaib Mujahid [:suhaib]]

Sorry, there was a problem with the detection of inactive users. I'm reverting the change.

Comment 5

[Hubert Boma Manilla (:bomsy)]

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

Bomsy, how far we are from landing this?

I'm holding back on this for a little bit, as we have use cases from users which might make them want to flip back to the old panel for now. Once we handle some of these we can comeback to removing this.

Comment 6

[BugBot [:suhaib / :marco]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Comment 7

[frank.loeffler]

In case this is about removing the code which gets used when devtools.netmonitor.features.newEditAndResend is set to 'False': please refrain from removing that until the new code got all capabilities of the old.

At least one of those is the ability to change all headers. The old one has this ability, but the new seems to be only able to display them, but users are not able to edit them anymore.

Comment 8

[Nicolas Chevobbe [:nchevobbe]]

(In reply to frank.loeffler from comment #7)

In case this is about removing the code which gets used when devtools.netmonitor.features.newEditAndResend is set to 'False': please refrain from removing that until the new code got all capabilities of the old.

At least one of those is the ability to change all headers. The old one has this ability, but the new seems to be only able to display them, but users are not able to edit them anymore.

Hello Frank. You can see that this bug depends on a few bugs, including Bug 1782037, which should cover your use case

Comment 9

[frank.loeffler]

Hi,

Thanks for the quick comment. I agree that the issue is related, but it is not the same. Bug #1782037 is about the ability to edit multiple headers at once. The issue I am describing is the current inability to edit specific headers (Referer is one example) in the new interface at all, even separately.

Comment 10

[Nicolas Chevobbe [:nchevobbe]]

(In reply to frank.loeffler from comment #9)

Hi,

Thanks for the quick comment. I agree that the issue is related, but it is not the same. Bug #1782037 is about the ability to edit multiple headers at once. The issue I am describing is the current inability to edit specific headers (Referer is one example) in the new interface at all, even separately.

bomsy might have the full story here, but I thought there was a list of headers that can't be modified as Firefox network layer will (has to?) set them by default, see Bug 1745413.
If setting the refer in the old edit and resend actually works, then we should remove it from the "read only" list

Comment 11

[frank.loeffler]

Hi,

I suspected as much. From https://developer.mozilla.org/en-US/docs/Glossary/Forbidden_request_header: "A forbidden request header is an HTTP header name-value pair that cannot be set or modified programmatically in a request." and "Modifying such headers is forbidden because the user agent retains full control over them."

It is not a header that cannot be modified at all. After all: firefox itself sets it, being the user agent. It is instead a header that should not be modifiable by, e.g., Javascript code. What we talk about here is "the dev tools of the user agent". They are part of the user agent. They are intended to do things "a normal user" would not do. They are intended to be useful to debug, and one of those things is the influence of headers, including the "forbidden ones". So, what I expect as a dev is that the dev tools of the user agent allow changing all headers of a request. I otherwise would have to copy the entire request into something like curl, which defeats the purpose of the dev tools.