Closed
Bug 1703786
Opened 3 years ago
Closed 3 years ago
Remove nsIHttpChannelInternal.hasNonEmptySandboxingFlag and use nsILoadInfo.sandboxFlags
Categories
(Core :: Networking: HTTP, task, P3)
Core
Networking: HTTP
Tracking
()
RESOLVED
FIXED
89 Branch
Tracking | Status | |
---|---|---|
firefox89 | --- | fixed |
People
(Reporter: valentin, Assigned: bomsy)
Details
(Whiteboard: [necko-triaged])
Attachments
(1 file)
We added hasNonEmptySandboxingFlag before nsILoadInfo.sandboxFlags existed.
We can remove it from nsIHttpChannelInternal and use the flags from the load info here
Assignee | ||
Updated•3 years ago
|
Assignee: nobody → hmanilla
Assignee | ||
Comment 1•3 years ago
•
|
||
Hi Valentin,
Just to clarify should all other occurrences / usages of hasNonEmptySandboxingFlag
be removed and replaced as well?
Flags: needinfo?(valentin.gosu)
Reporter | ||
Comment 2•3 years ago
|
||
Yes. It is no longer necessary to be stored or passed around via IPC as we already have it on the loadInfo.
Pretty much every instance of the string should be removed, except here where we should say:
if (resultPolicy != nsILoadInfo::OPENER_POLICY_UNSAFE_NONE &&
mLoadInfo->GetSandboxFlags()) {
Flags: needinfo?(valentin.gosu)
Assignee | ||
Comment 3•3 years ago
|
||
Pushed by hmanilla@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/3747f3999718 Use nsILoadInfo.sandboxFlags instead r=valentin,necko-reviewers
Comment 5•3 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 3 years ago
status-firefox89:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 89 Branch
You need to log in
before you can comment on or make changes to this bug.
Description
•