+cbiesinger@ for code review and owner approval of content/browser/webid/, thank you.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
lgtm
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
+alexrudenko@ for owner approval of content/browser/devtools/ devtools_instrumentation.cc.
+chrome-ipc-reviews@ for approval of third_party/blink/public/mojom/devtools/ inspector_issue.mojom.
Thank you.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
From googleclient/chrome/chromium_gwsq/ipc/config.gwsq:
Shadow: ari...@chromium.org; IPC: ke...@chromium.org
📎 It looks like you’re making a possibly security-sensitive change! 📎 IPC security review isn’t a rubberstamp, so your friendly security reviewer will need a fair amount of context to review your CL effectively. Please review your CL description and code comments to make sure they provide context for someone unfamiliar with your project/area. Pay special attention to where data comes from and which processes it flows between (and their privilege levels). Feel free to point your security reviewer at design docs, bugs, or other links if you can’t reasonably make a self-contained CL description. (Also see https://cbea.ms/git-commit/).
Shadow IPC reviewer(s): ari...@chromium.org. Please conduct an IPC review and CR+1 when satisfied. Remember to add the main reviewers to the attention set if needed.
Main IPC reviewer(s): ke...@chromium.org. Please wait for the shadowed IPC reviewer to CR+1 before reviewing.
Shadowed: ari...@chromium.org
Reviewer source(s):
ari...@chromium.org, ke...@chromium.org is from context(googleclient/chrome/chromium_gwsq/ipc/config.gwsq)
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
// third_party/blink/public/devtools_protocol/domains/Audits.pdl, which includesShould this file be updated as well?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
// third_party/blink/public/devtools_protocol/domains/Audits.pdl, which includesShould this file be updated as well?
I assumed that wasn't included as it's not being harnessed in content/browser/devtools/devtools_instrumentation.cc (the TODOs make that seems like it's the next step)
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
// third_party/blink/public/devtools_protocol/domains/Audits.pdl, which includesAri ChivukulaShould this file be updated as well?
I assumed that wasn't included as it's not being harnessed in content/browser/devtools/devtools_instrumentation.cc (the TODOs make that seems like it's the next step)
I was planning to update this file in the next CL that implements the devtool issues: crrev.com/c/8122679. Should I combine that into this CL?
// third_party/blink/public/devtools_protocol/domains/Audits.pdl, which includesAri ChivukulaShould this file be updated as well?
Xiaochen ZhouI assumed that wasn't included as it's not being harnessed in content/browser/devtools/devtools_instrumentation.cc (the TODOs make that seems like it's the next step)
I was planning to update this file in the next CL that implements the devtool issues: crrev.com/c/8122679. Should I combine that into this CL?
I'm fine with it being split as the IPC is just enums, there's not some big e2e component that isn't being validated here to prove the mojo change
| Code-Review | +1 |
// third_party/blink/public/devtools_protocol/domains/Audits.pdl, which includesAri ChivukulaShould this file be updated as well?
Xiaochen ZhouI assumed that wasn't included as it's not being harnessed in content/browser/devtools/devtools_instrumentation.cc (the TODOs make that seems like it's the next step)
Ari ChivukulaI was planning to update this file in the next CL that implements the devtool issues: crrev.com/c/8122679. Should I combine that into this CL?
I'm fine with it being split as the IPC is just enums, there's not some big e2e component that isn't being validated here to prove the mojo change
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
case FederatedRequestResult::kWellKnownBlockedByConnectionAllowlist:It looks like the protocol change that generates the enums is added in this CL (third_party/blink/public/devtools_protocol/domains/Audits.pdl) Is there a reason not to mapa the result codes to the new enum values?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |