Commit-Queue | +1 |
void ActivateDevToolsTransform(const DeviceEmulationParams&,
Alex RudenkoBlink Style Guide: Prefer enums or StrongAliases to bare bools for function parameters. The meaning of the 'restore' boolean is not clear at call sites. Please consider using a `base::StrongAlias` or an enum to improve readability, for example `using RestoreState = base::StrongAlias<class RestoreStateTag, bool>;`.
_To keep this interaction as brief and non-intrusive as possible, please consider responding with one of following options:
**Done** | **Won't fix**: reason | **b/<bug_id>** | **Invalid:** reasonThis comment was generated by [Experimental Blink C++ Code Review Agent](http://go/blink-c++-code-review-agent).AI reviews can sometimes be inaccurate; We appreciate your 🙏 feedback 🙏 to help us improve.[File a bug](http://go/blink-c++-code-review-agent-feedback) | [Provide feedback on chat](https://chat.google.com/room/AAQA0zhQHe0?cls=4) | [Opt-out](https://ganpati2.corp.google.com/group/peep-genai-blink-agent-optout.prod)_
Done
void ChangeEmulationParams(const DeviceEmulationParams& params,
Alex RudenkoBlink Style Guide: Prefer enums or StrongAliases to bare bools for function parameters. The meaning of the 'restore' boolean is not clear at call sites. Please consider using a `base::StrongAlias` or an enum to improve readability, for example `using RestoreState = base::StrongAlias<class RestoreStateTag, bool>;`.
_To keep this interaction as brief and non-intrusive as possible, please consider responding with one of following options:
**Done** | **Won't fix**: reason | **b/<bug_id>** | **Invalid:** reasonThis comment was generated by [Experimental Blink C++ Code Review Agent](http://go/blink-c++-code-review-agent).AI reviews can sometimes be inaccurate; We appreciate your 🙏 feedback 🙏 to help us improve.[File a bug](http://go/blink-c++-code-review-agent-feedback) | [Provide feedback on chat](https://chat.google.com/room/AAQA0zhQHe0?cls=4) | [Opt-out](https://ganpati2.corp.google.com/group/peep-genai-blink-agent-optout.prod)_
Done
void EnableDeviceEmulation(const DeviceEmulationParams& parameters,
Alex RudenkoBlink Style Guide: Prefer enums or StrongAliases to bare bools for function parameters. The meaning of the 'restore' boolean is not clear at call sites. Please consider using a `base::StrongAlias` or an enum to improve readability, for example `using RestoreState = base::StrongAlias<class RestoreStateTag, bool>;`.
_To keep this interaction as brief and non-intrusive as possible, please consider responding with one of following options:
**Done** | **Won't fix**: reason | **b/<bug_id>** | **Invalid:** reasonThis comment was generated by [Experimental Blink C++ Code Review Agent](http://go/blink-c++-code-review-agent).AI reviews can sometimes be inaccurate; We appreciate your 🙏 feedback 🙏 to help us improve.[File a bug](http://go/blink-c++-code-review-agent-feedback) | [Provide feedback on chat](https://chat.google.com/room/AAQA0zhQHe0?cls=4) | [Opt-out](https://ganpati2.corp.google.com/group/peep-genai-blink-agent-optout.prod)_
Done
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Code-Review | +1 |
const blink::mojom::DeviceEmulationUpdateReason restore) override {}
const ref?
const mojom::blink::DeviceEmulationUpdateReason reason) override;
const ref?
const mojom::blink::DeviceEmulationUpdateReason reason) {
const ref?
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
const blink::mojom::DeviceEmulationUpdateReason restore) override {}
Alex Rudenkoconst ref?
it is not compatible with the base class generated based on mojom so I think it's not possible?
const mojom::blink::DeviceEmulationUpdateReason reason) override;
Alex Rudenkoconst ref?
ditto
const mojom::blink::DeviceEmulationUpdateReason reason) {
Alex Rudenkoconst ref?
ditto
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
From googleclient/chrome/chromium_gwsq/ipc/config.gwsq:
IPC: arthurs...@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): arthurs...@chromium.org
Note: IPC gwsq added no new reviewers; existing reviewers satisfied requirements!
Reviewer source(s):
arthurs...@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. |
EnableDeviceEmulation(DeviceEmulationParams parameters, DeviceEmulationUpdateReason reason);
Nit: wrap at 80 (git cl format --mojom might fix this)
reason != mojom::blink::DeviceEmulationUpdateReason::kRestore) {
I don't think it's entirely obvious why:
I think comments here and perhaps different names for the reason variants might help?
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
const blink::mojom::DeviceEmulationUpdateReason restore) override {}
The parameter is named `reason` in every other part of the patch (the Mojo interface, implementation files, etc.). Renaming `restore` to `reason` here would improve consistency, even in a test mock.
reason != mojom::blink::DeviceEmulationUpdateReason::kRestore) {
I don't think it's entirely obvious why:
- we have to evict the memory cache at all to begin with
- why `kRestore` is exempt from this
I think comments here and perhaps different names for the reason variants might help?
+1.
Commit-Queue | +1 |
const blink::mojom::DeviceEmulationUpdateReason restore) override {}
The parameter is named `reason` in every other part of the patch (the Mojo interface, implementation files, etc.). Renaming `restore` to `reason` here would improve consistency, even in a test mock.
Done
EnableDeviceEmulation(DeviceEmulationParams parameters, DeviceEmulationUpdateReason reason);
Nit: wrap at 80 (git cl format --mojom might fix this)
Thanks, `git cl format --mojom` fixed it but there were a bunch of unrelated fixes (I reverted those). Curious if there is there a reason why mojom formatter does not run by default?
reason != mojom::blink::DeviceEmulationUpdateReason::kRestore) {
Arthur SonzogniI don't think it's entirely obvious why:
- we have to evict the memory cache at all to begin with
- why `kRestore` is exempt from this
I think comments here and perhaps different names for the reason variants might help?
+1.
Thanks, I have added a comment here explaining the situation. I have not renamed the variable and enums so far to hear if you have any suggestions on what names would make it clearer?
reason != mojom::blink::DeviceEmulationUpdateReason::kRestore) {
Arthur SonzogniI don't think it's entirely obvious why:
- we have to evict the memory cache at all to begin with
- why `kRestore` is exempt from this
I think comments here and perhaps different names for the reason variants might help?
Alex Rudenko+1.
Thanks, I have added a comment here explaining the situation. I have not renamed the variable and enums so far to hear if you have any suggestions on what names would make it clearer?
Maybe it should just be named for what it does: whether or not to invalidate the memory cache?
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
reason != mojom::blink::DeviceEmulationUpdateReason::kRestore) {
Arthur SonzogniI don't think it's entirely obvious why:
- we have to evict the memory cache at all to begin with
- why `kRestore` is exempt from this
I think comments here and perhaps different names for the reason variants might help?
Alex Rudenko+1.
Daniel ChengThanks, I have added a comment here explaining the situation. I have not renamed the variable and enums so far to hear if you have any suggestions on what names would make it clearer?
Maybe it should just be named for what it does: whether or not to invalidate the memory cache?
I checked and it does appear that memory cache behavior is the only piece of the per-process logic here so I renamed the enum accordingly:
```
enum DeviceEmulationCacheBehavior {
// Clear memory cache when emulation parameters change.
kClearCache,
// Keep the memory cache when emulation parameters change.
kKeepCache,
};
```
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Code-Review | +1 |
// Keep the memory cache when emulation parameters change.
It would be nice to give a brief example here of when a caller would use it. Something like:
"Typically used when committing a navigation in a new Document, which has to re-sync the device emulation state, but should not clobber the global memory cache since the parameters did not actually change."
DeviceEmulationParams parameters, DeviceEmulationCacheBehavior cache_behavior);
Nit: wrapping :)
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
// Keep the memory cache when emulation parameters change.
It would be nice to give a brief example here of when a caller would use it. Something like:
"Typically used when committing a navigation in a new Document, which has to re-sync the device emulation state, but should not clobber the global memory cache since the parameters did not actually change."
Done, thanks!
DeviceEmulationParams parameters, DeviceEmulationCacheBehavior cache_behavior);
Alex RudenkoNit: wrapping :)
Done
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. |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
DevTools: do not clear memory cache when restoring emulation
With RenderDocument, the codepath that syncs device emulation
settings with new renderers runs for every navigation. That prevents
memory caches from working as expected on navigation (and reload).
This CL adds the indication of the reason for the device emulation
parameters update to skip the cache logic.
Drive-by: adds missing tests for the Network.restoredFromCache.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |