Hi all. As discussed in https://crrev.com/c/7269607 and via email, this CL renames network::OriginatingProcess to network::OriginatingProcessId and network::RendererProcess to network::RendererProcessId. I think this warrants an OO. Please let me know if there's any other procedure that is required.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
From googleclient/chrome/chromium_gwsq/ipc/config.gwsq:
IPC: ort...@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/).
IPC reviewer(s): ort...@chromium.org
Reviewer source(s):
ort...@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. |
// Whether the originating process is the browser process.
bool is_browser() const;
// Get the renderer process ID for this, it is a bug to call this if
// |is_browser| returns true.
const RendererProcessId& renderer_process() const;More of a question than a request for change: how come we don't suffix these with `_id`?
*out = network::OriginatingProcessId::browser();look like if the tag is kBrowserProcessId, we assume the data is valid. Can we change that to verifying that the data is actually valid?
Would the following work?
```
netowrk::mojom::BrowserProcessId browser_process;
if (!data.ReadBrowserProcessId(&browser_process)) {
return false;
}
*out = network::OriginatingProcessId::browser();
```
network::RendererProcessId renderer_process;optional nit: we're suffixing the types with Id, so it would make snse to also do that with variables names.
data.GetRendererProcessIdDataView(&view);
if (!StructTraits<decltype(view), decltype(renderer_process)>::Read(
std::move(view), &renderer_process)) {
return false;
}why do we use the data view and Read instead of:
```
if (!data.ReadRenderProcessId(&renderer_process)) {
return false;
}
*out = network::OriginatingProcessId::renderer(std::move(renderer_process));
```
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
// Whether the originating process is the browser process.
bool is_browser() const;
// Get the renderer process ID for this, it is a bug to call this if
// |is_browser| returns true.
const RendererProcessId& renderer_process() const;More of a question than a request for change: how come we don't suffix these with `_id`?
You're absolutely right, I probably should.
*out = network::OriginatingProcessId::browser();look like if the tag is kBrowserProcessId, we assume the data is valid. Can we change that to verifying that the data is actually valid?
Would the following work?
```
netowrk::mojom::BrowserProcessId browser_process;
if (!data.ReadBrowserProcessId(&browser_process)) {
return false;
}
*out = network::OriginatingProcessId::browser();
```
The struct is empty, so I don't think there's anything to read. But it sure doesn't hurt to add it.
network::RendererProcessId renderer_process;optional nit: we're suffixing the types with Id, so it would make snse to also do that with variables names.
Done
data.GetRendererProcessIdDataView(&view);
if (!StructTraits<decltype(view), decltype(renderer_process)>::Read(
std::move(view), &renderer_process)) {
return false;
}why do we use the data view and Read instead of:
```
if (!data.ReadRenderProcessId(&renderer_process)) {
return false;
}
*out = network::OriginatingProcessId::renderer(std::move(renderer_process));
```
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
mojo lgtm % nit
if (data.is_null()) {
return false;
}I believe this is checked by the bindings, so we should be able to assume the data is non-null[[1]](https://source.chromium.org/chromium/chromium/src/+/main:out/linux-Debug/gen/services/network/public/mojom/originating_process.mojom-shared.h;l=170;drc=57413c5806942e56350114a0ab9daa26de64b4bc).
Did you run into any cases where data is null here?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
I believe this is checked by the bindings, so we should be able to assume the data is non-null[[1]](https://source.chromium.org/chromium/chromium/src/+/main:out/linux-Debug/gen/services/network/public/mojom/originating_process.mojom-shared.h;l=170;drc=57413c5806942e56350114a0ab9daa26de64b4bc).
Did you run into any cases where data is null here?
I did not. I saw the function existed and decided to add it. If it's checked in the bindings then I'm happy to revert.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Shadowed: arthurm...@google.com
Reviewer source(s):
arthurm...@google.com, dro...@chromium.org is from context(googleclient/chrome/chromium_gwsq/components/signin/config.gwsq)
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
I don’t know why I was added, there is no iles I own here.
FYI, the standard chrome way to do this (and probably the only way you can get it done due to the number of merge conflict git CL gets) is:
I’m sorry that this is much extra work. But even with owner override, the problem of merge conflict remains.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
It might be easier to get this CL merged by splitting it up. Create an alias for the old name, then migrate call sites piece by piece before you remove the old name?
It might be easier to get this CL merged by splitting it up. Create an alias for the old name, then migrate call sites piece by piece before you remove the old name?
That's a good idea. I'm not sure how well I can break it up due to the mojom rewriting. I'll take a look.
I don’t know why I was added, there is no iles I own here.
FYI, the standard chrome way to do this (and probably the only way you can get it done due to the number of merge conflict git CL gets) is:
- you introduce `ChildProcessId`, and define `ChildProcess` as an alias for `ChildProcessId ` in a first CL
- You then use the shell command `git cl split` to split the CL in a lot of smaller CLs that can be more easily reviewed by the owners of various parts.
- If you still get merge conflict, you rebase those smaller conflicts
- once all are merged, you remove the alias
I’m sorry that this is much extra work. But even with owner override, the problem of merge conflict remains.
Thanks, I think you were auto-added as Chrome Signin Team for login_handler_unittest.cc. Thanks for the information.
Christopher StaiteIt might be easier to get this CL merged by splitting it up. Create an alias for the old name, then migrate call sites piece by piece before you remove the old name?
That's a good idea. I'm not sure how well I can break it up due to the mojom rewriting. I'll take a look.
Another possible route, find someone relevant with owner-override powers (and does timely reviews):
https://chromium.googlesource.com/chromium/src/+/HEAD/docs/code_review_owners.md#what-should-i-do-when-i-need-to-get-owners_override-for-one_off-cls
You can call out that this is basically a *mechanical* search and replace in the CL description.
| Code-Review | +1 |
| Owners-Override | +1 |
Christopher StaiteIt might be easier to get this CL merged by splitting it up. Create an alias for the old name, then migrate call sites piece by piece before you remove the old name?
Bo LiuThat's a good idea. I'm not sure how well I can break it up due to the mojom rewriting. I'll take a look.
Another possible route, find someone relevant with owner-override powers (and does timely reviews):
https://chromium.googlesource.com/chromium/src/+/HEAD/docs/code_review_owners.md#what-should-i-do-when-i-need-to-get-owners_override-for-one_off-clsYou can call out that this is basically a *mechanical* search and replace in the CL description.
I have the power, and have reviewed the entire CL.
Christopher StaiteIt might be easier to get this CL merged by splitting it up. Create an alias for the old name, then migrate call sites piece by piece before you remove the old name?
Bo LiuThat's a good idea. I'm not sure how well I can break it up due to the mojom rewriting. I'll take a look.
Dave TapuskaAnother possible route, find someone relevant with owner-override powers (and does timely reviews):
https://chromium.googlesource.com/chromium/src/+/HEAD/docs/code_review_owners.md#what-should-i-do-when-i-need-to-get-owners_override-for-one_off-clsYou can call out that this is basically a *mechanical* search and replace in the CL description.
I have the power, and have reviewed the entire CL.
Thank you! I have rebased which hopefully fixed the merge conflict, there was no merge conflict detected locally by Git.
I will take the advise on how to approach this in future under my belt.
Christopher StaiteI don’t know why I was added, there is no iles I own here.
FYI, the standard chrome way to do this (and probably the only way you can get it done due to the number of merge conflict git CL gets) is:
- you introduce `ChildProcessId`, and define `ChildProcess` as an alias for `ChildProcessId ` in a first CL
- You then use the shell command `git cl split` to split the CL in a lot of smaller CLs that can be more easily reviewed by the owners of various parts.
- If you still get merge conflict, you rebase those smaller conflicts
- once all are merged, you remove the alias
I’m sorry that this is much extra work. But even with owner override, the problem of merge conflict remains.
Thanks, I think you were auto-added as Chrome Signin Team for login_handler_unittest.cc. Thanks for the information.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
| Code-Review | +1 |
Rename OriginatingProcess to OriginatingProcessId
In https://crrev.com/c/7498491 the new types network::OriginatingProcess
and network::RendererProcess were introduced to mirror
content::ChildProcessId. However, since then in using these types it
has caused some confusion due to a poor choice of name. These are not
functional types, simply IDs referring to a process.
This CL resolves that naming issue before this persists and renames
network::OriginatingProcess to network::OriginatingProcessId and
network::RendererProcess to network::RendererProcessId. There is no
functional change, simply a type renaming.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |