Remove usage of windowIdToFrameIdMap in the Network observer
Categories
(Remote Protocol :: CDP, enhancement, P1)
Tracking
(Fission Milestone:Future, firefox80 fixed)
| Tracking | Status | |
|---|---|---|
| firefox80 | --- | fixed |
People
(Reporter: whimboo, Assigned: whimboo)
Details
Attachments
(1 file)
Currently we use a Map to translate the inner window id to the browsing context id of the frame where the network activity takes place:
As I just noticed this map is not necessary. Instead we can use the httpChannel.loadInfo.frameBrowsingContextID to identify the frame id for the sub requests.
|
||
Comment 1•5 years ago
|
||
(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] from comment #0)
As I just noticed this map is not necessary. Instead we can use the httpChannel.loadInfo.frameBrowsingContextID to identify the frame id for the sub requests.
IIUC, this is a cleanup bug and doesn't need to block shipping Fission MVP.
|
Assignee | |
Comment 2•5 years ago
|
||
I had a quick check and it actually doesn't seem to be that trivial. I still see null objects for the frameBrowsingContext. So maybe it might not be possible. But further investigation needs to be done here.
|
|
Assignee | |
Comment 3•5 years ago
|
||
Bug 1580764 just added support for the frameId to the ChannelWrapper interface. As such we should be able to get rid of our custom map.
|
|
Assignee | |
Comment 4•5 years ago
|
||
Actually frameId will be 0 for the top-browsing context. It means that for resource requests/responses we won't have a valid number. But we can actually make use of the browsingContext and frameBrowsingContext properties on the httpChannel.loadInfo object.
|
|
Assignee | |
Comment 5•5 years ago
|
||
|
||
Updated•5 years ago
|
|
|
Assignee | |
Updated•5 years ago
|
|
|
||
Updated•5 years ago
|
|
|
Assignee | |
Updated•5 years ago
|
|
||
Comment 7•5 years ago
|
||
| bugherder | ||
|
||
Updated•4 years ago
|
Description
•