|
|
DescriptionAdd configuration_changed event and set_background_opacity request.
* remote shell API version is updated to 9.
* Send the current primary display info because primary display is dynamic and can change or even go away.
* This also fixed a bug where a underlay wasn't created when it started maximized.
BUG=632083
TEST=tested on new and old impl on android side. Updated unit test.
Committed: https://crrev.com/80d20b2f6bc5a6aa8e0caa37f517aef783d3186d
Cr-Commit-Position: refs/heads/master@{#409089}
Patch Set 1 #
Total comments: 1
Patch Set 2 : updated interface comment #
Total comments: 29
Patch Set 3 : addressed comment #Patch Set 4 : addressed comments #
Total comments: 1
Patch Set 5 : fixed to double #
Total comments: 1
Patch Set 6 : rebase #
Total comments: 8
Patch Set 7 : Add display_changed event and set_background_opacity request. #
Total comments: 1
Patch Set 8 : revert primary display change #Patch Set 9 : formatting #Messages
Total messages: 46 (31 generated)
Patchset #1 (id:1) has been deleted
Description was changed from ========== Add display_changed event and set_background_opacity request. * This also fixed a bug where a underlay wasn't created when it started maximized. BUG=632083 ========== to ========== Add display_changed event and set_background_opacity request. * Send the current primary display info because primary display is dynamic and can change or even go away. * This also fixed a bug where a underlay wasn't created when it started maximized. BUG=632083 ==========
Description was changed from ========== Add display_changed event and set_background_opacity request. * Send the current primary display info because primary display is dynamic and can change or even go away. * This also fixed a bug where a underlay wasn't created when it started maximized. BUG=632083 ========== to ========== Add display_changed event and set_background_opacity request. * Send the current primary display info because primary display is dynamic and can change or even go away. * This also fixed a bug where a underlay wasn't created when it started maximized. BUG=632083 TEST=tested on new and old impl on android side. Updated unit test. ==========
oshima@chromium.org changed reviewers: + reveman@chromium.org
The CQ bit was checked by oshima@chromium.org to run a CQ dry run
https://codereview.chromium.org/2189073003/diff/20001/components/exo/shell_su... File components/exo/shell_surface_unittest.cc (left): https://codereview.chromium.org/2189073003/diff/20001/components/exo/shell_su... components/exo/shell_surface_unittest.cc:647: } // namespace I remove this from the test bodies for test fixtures, but I think this also matches the test harness expectation that test names are globally unique (--gtest_filter=)
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
The CQ bit was checked by oshima@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Description was changed from ========== Add display_changed event and set_background_opacity request. * Send the current primary display info because primary display is dynamic and can change or even go away. * This also fixed a bug where a underlay wasn't created when it started maximized. BUG=632083 TEST=tested on new and old impl on android side. Updated unit test. ========== to ========== Add display_changed event and set_background_opacity request. * remote shell API version is updated to 9. * Send the current primary display info because primary display is dynamic and can change or even go away. * This also fixed a bug where a underlay wasn't created when it started maximized. BUG=632083 TEST=tested on new and old impl on android side. Updated unit test. ==========
https://codereview.chromium.org/2189073003/diff/40001/components/exo/wayland/... File components/exo/wayland/server.cc (right): https://codereview.chromium.org/2189073003/diff/40001/components/exo/wayland/... components/exo/wayland/server.cc:1067: void SendDisplayMetricsObsolete(const display::Display& display) { There's nothing obsolete about this code. wl_output is still the correct interface to use by non-arc clients. https://codereview.chromium.org/2189073003/diff/40001/components/exo/wayland/... components/exo/wayland/server.cc:1687: void SendConfigureObsolete() { Maybe SendConfigure_DEPRECATED to make it even more clear that this should be removed when we create a new interface for this remote-shell functionality https://codereview.chromium.org/2189073003/diff/40001/components/exo/wayland/... components/exo/wayland/server.cc:1704: void SendLayoutModeChange(uint32_t mode) { is this not deprecated too? https://codereview.chromium.org/2189073003/diff/40001/third_party/wayland-pro... File third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml (right): https://codereview.chromium.org/2189073003/diff/40001/third_party/wayland-pro... third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml:154: <event name="display_changed" since="9"> nit: we don't really have a "display" concept in any of the wayland interfaces. if anything, "display" is the display server and basically what implements the compositor and all other interfaces. can we keep referring to this as just the "shell" and simply say that the shell configuration changed, name="configuration_changed"? Fyi, instead of deprecating the old events it would be ok to add additional configure events and a configure_done event at the end. that's a more common way of extending wayland interfaces. e.g. wl_output was extended this way. Either way is fine with me though. https://codereview.chromium.org/2189073003/diff/40001/third_party/wayland-pro... third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml:155: <description summary="suggests a re-configuration of display for remote shell"> nit: s/of display for remote shell/of remote shell/ https://codereview.chromium.org/2189073003/diff/40001/third_party/wayland-pro... third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml:156: Suggests a re-configuration of display for remote shell. nit: ditto https://codereview.chromium.org/2189073003/diff/40001/third_party/wayland-pro... third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml:159: <arg name="output_origin_y" type="int"/> nit: origin_x/y btw, what's this used for? do we need it? https://codereview.chromium.org/2189073003/diff/40001/third_party/wayland-pro... third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml:161: <arg name="output_height_mm" type="int"/> nit: width/height_mm https://codereview.chromium.org/2189073003/diff/40001/third_party/wayland-pro... third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml:162: <arg name="output_subpixel_layout" type="int"/> nit: subpixel_layout, do we really need this? https://codereview.chromium.org/2189073003/diff/40001/third_party/wayland-pro... third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml:163: <arg name="output_transform" type="int"/> nit: name="transform" https://codereview.chromium.org/2189073003/diff/40001/third_party/wayland-pro... third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml:166: <arg name="output_mode_height_pixels" type="int"/> do we need these? is display_width/height below not enough? https://codereview.chromium.org/2189073003/diff/40001/third_party/wayland-pro... third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml:167: <arg name="output_mode_refresh_rate_mhz" type="int"/> please remove if not needed https://codereview.chromium.org/2189073003/diff/40001/third_party/wayland-pro... third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml:168: <arg name="display_scale_factor" type="fixed"/> nit: name="scale_factor" https://codereview.chromium.org/2189073003/diff/40001/third_party/wayland-pro... third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml:170: <arg name="display_height" type="int"/> nit: name="width"/"height" https://codereview.chromium.org/2189073003/diff/40001/third_party/wayland-pro... third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml:501: <request name="set_background_opacity" since="9"> nit: set_rectangular_shadow_background_opacity as I don't think this should apply unless a rectangular shadow is requested qq, should this just change the opacity of the background or also the shadow itself?
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
https://codereview.chromium.org/2189073003/diff/40001/components/exo/wayland/... File components/exo/wayland/server.cc (right): https://codereview.chromium.org/2189073003/diff/40001/components/exo/wayland/... components/exo/wayland/server.cc:1067: void SendDisplayMetricsObsolete(const display::Display& display) { On 2016/07/28 19:52:01, reveman wrote: > There's nothing obsolete about this code. wl_output is still the correct > interface to use by non-arc clients. Done. https://codereview.chromium.org/2189073003/diff/40001/components/exo/wayland/... components/exo/wayland/server.cc:1687: void SendConfigureObsolete() { On 2016/07/28 19:52:01, reveman wrote: > Maybe SendConfigure_DEPRECATED to make it even more clear that this should be > removed when we create a new interface for this remote-shell functionality Done. https://codereview.chromium.org/2189073003/diff/40001/components/exo/wayland/... components/exo/wayland/server.cc:1704: void SendLayoutModeChange(uint32_t mode) { On 2016/07/28 19:52:01, reveman wrote: > is this not deprecated too? Done. https://codereview.chromium.org/2189073003/diff/40001/third_party/wayland-pro... File third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml (right): https://codereview.chromium.org/2189073003/diff/40001/third_party/wayland-pro... third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml:154: <event name="display_changed" since="9"> On 2016/07/28 19:52:02, reveman wrote: > nit: we don't really have a "display" concept in any of the wayland interfaces. > if anything, "display" is the display server and basically what implements the > compositor and all other interfaces. can we keep referring to this as just the > "shell" and simply say that the shell configuration changed, > name="configuration_changed"? done. > Fyi, instead of deprecating the old events it would be ok to add additional > configure events and a configure_done event at the end. that's a more common way > of extending wayland interfaces. e.g. wl_output was extended this way. Either > way is fine with me though. that's good to know. For this, I think it's good chance to consolidate them before cleaning up the interface, so I'll keep this. I'll add _done when we need more. https://codereview.chromium.org/2189073003/diff/40001/third_party/wayland-pro... third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml:155: <description summary="suggests a re-configuration of display for remote shell"> On 2016/07/28 19:52:02, reveman wrote: > nit: s/of display for remote shell/of remote shell/ Done. https://codereview.chromium.org/2189073003/diff/40001/third_party/wayland-pro... third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml:156: Suggests a re-configuration of display for remote shell. On 2016/07/28 19:52:01, reveman wrote: > nit: ditto Done. https://codereview.chromium.org/2189073003/diff/40001/third_party/wayland-pro... third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml:159: <arg name="output_origin_y" type="int"/> On 2016/07/28 19:52:02, reveman wrote: > nit: origin_x/y > > btw, what's this used for? do we need it? Removed. https://codereview.chromium.org/2189073003/diff/40001/third_party/wayland-pro... third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml:161: <arg name="output_height_mm" type="int"/> On 2016/07/28 19:52:02, reveman wrote: > nit: width/height_mm Done. https://codereview.chromium.org/2189073003/diff/40001/third_party/wayland-pro... third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml:162: <arg name="output_subpixel_layout" type="int"/> On 2016/07/28 19:52:02, reveman wrote: > nit: subpixel_layout, do we really need this? Removed. We may need it in the future for proper font rendering, but we can add it later. https://codereview.chromium.org/2189073003/diff/40001/third_party/wayland-pro... third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml:163: <arg name="output_transform" type="int"/> On 2016/07/28 19:52:02, reveman wrote: > nit: name="transform" Done. https://codereview.chromium.org/2189073003/diff/40001/third_party/wayland-pro... third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml:166: <arg name="output_mode_height_pixels" type="int"/> On 2016/07/28 19:52:02, reveman wrote: > do we need these? is display_width/height below not enough? They're both used (for physical size and logical pixel). I changed to pass dpi + physical pixel size. I think this is better. https://codereview.chromium.org/2189073003/diff/40001/third_party/wayland-pro... third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml:167: <arg name="output_mode_refresh_rate_mhz" type="int"/> On 2016/07/28 19:52:01, reveman wrote: > please remove if not needed It looks to me this is used. (it's passed to hwc) If you think we can just hard code the same value in here, let me know. https://codereview.chromium.org/2189073003/diff/40001/third_party/wayland-pro... third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml:170: <arg name="display_height" type="int"/> On 2016/07/28 19:52:02, reveman wrote: > nit: name="width"/"height" done. https://codereview.chromium.org/2189073003/diff/40001/third_party/wayland-pro... third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml:501: <request name="set_background_opacity" since="9"> On 2016/07/28 19:52:02, reveman wrote: > nit: set_rectangular_shadow_background_opacity as I don't think this should > apply unless a rectangular shadow is requested > > qq, should this just change the opacity of the background or also the shadow > itself? I'd just change the background for now. We can adjust when we get feedback.
https://codereview.chromium.org/2189073003/diff/80001/components/exo/wayland/... File components/exo/wayland/server.cc (left): https://codereview.chromium.org/2189073003/diff/80001/components/exo/wayland/... components/exo/wayland/server.cc:1041: WaylandDisplayObserver(const display::Display& display, I also changed the wayland output events to use current primary display.
rebased https://codereview.chromium.org/2189073003/diff/100001/components/exo/wayland... File components/exo/wayland/server.cc (right): https://codereview.chromium.org/2189073003/diff/100001/components/exo/wayland... components/exo/wayland/server.cc:1611: } I'll put this back when I merge to 53.
https://codereview.chromium.org/2189073003/diff/120001/components/exo/shell_s... File components/exo/shell_surface_unittest.cc (right): https://codereview.chromium.org/2189073003/diff/120001/components/exo/shell_s... components/exo/shell_surface_unittest.cc:46: } // namespace can we make this change in a separate patch and change all unittest.cc files for consistency? https://codereview.chromium.org/2189073003/diff/120001/components/exo/wayland... File components/exo/wayland/server.cc (left): https://codereview.chromium.org/2189073003/diff/120001/components/exo/wayland... components/exo/wayland/server.cc:1043: WaylandDisplayObserver(const display::Display& display, this code was structured this way so that WaylandDisplayObserver class would have proper support for multiple displays and that limitation was kept outside this class. I'd prefer to keep it that way. Is there an important reason for changing it in this patch? https://codereview.chromium.org/2189073003/diff/120001/third_party/wayland-pr... File third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml (right): https://codereview.chromium.org/2189073003/diff/120001/third_party/wayland-pr... third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml:165: <arg name="height" type="int"/> I took a good look at our client code and the only arguments out of the above that we really need are the following: <arg name="width" type="int"/> <arg name="height" type="int"/> <arg name="transform" type="int"/> <arg name="scale_factor" type="fixed"/> as refresh rate is not really used as we now provide proper vsync events so it's fine to hard code 60hz in hwc code. dpi and physical size can't change on the client side so it's much better to just compute those values there based on the density property. Ping me if this doesn't match what you see in the client code.
https://codereview.chromium.org/2189073003/diff/120001/components/exo/shell_s... File components/exo/shell_surface_unittest.cc (right): https://codereview.chromium.org/2189073003/diff/120001/components/exo/shell_s... components/exo/shell_surface_unittest.cc:46: } // namespace On 2016/07/29 16:03:51, reveman wrote: > can we make this change in a separate patch and change all unittest.cc files for > consistency? I'll send a CL soon. (I need this in here for now. I'll rebase once it's landed) https://codereview.chromium.org/2189073003/diff/120001/components/exo/wayland... File components/exo/wayland/server.cc (left): https://codereview.chromium.org/2189073003/diff/120001/components/exo/wayland... components/exo/wayland/server.cc:1043: WaylandDisplayObserver(const display::Display& display, On 2016/07/29 16:03:51, reveman wrote: > this code was structured this way so that WaylandDisplayObserver class would > have proper support for multiple displays and that limitation was kept outside > this class. I'd prefer to keep it that way. Is there an important reason for > changing it in this patch? It's simply wrong to keep the display id because primary display isn't persistent thing. It's nothing to do with multi display. (You can plug in your laptop to external display, close the lid, then the primary display switches to the external display, which has different id) https://codereview.chromium.org/2189073003/diff/120001/third_party/wayland-pr... File third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml (right): https://codereview.chromium.org/2189073003/diff/120001/third_party/wayland-pr... third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml:165: <arg name="height" type="int"/> On 2016/07/29 16:03:51, reveman wrote: > I took a good look at our client code and the only arguments out of the above > that we really need are the following: > > <arg name="width" type="int"/> > <arg name="height" type="int"/> > <arg name="transform" type="int"/> > <arg name="scale_factor" type="fixed"/> > > as refresh rate is not really used as we now provide proper vsync events so it's > fine to hard code 60hz in hwc code. dpi and physical size can't change on the > client side so it's much better to just compute those values there based on the > density property. Are you suggesting to just give them fake value? There is no way to get the correct value even for the first detected one without them. > > Ping me if this doesn't match what you see in the client code.
The CQ bit was checked by oshima@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Description was changed from ========== Add display_changed event and set_background_opacity request. * remote shell API version is updated to 9. * Send the current primary display info because primary display is dynamic and can change or even go away. * This also fixed a bug where a underlay wasn't created when it started maximized. BUG=632083 TEST=tested on new and old impl on android side. Updated unit test. ========== to ========== Add configuration_changed event and set_background_opacity request. * remote shell API version is updated to 9. * Send the current primary display info because primary display is dynamic and can change or even go away. * This also fixed a bug where a underlay wasn't created when it started maximized. BUG=632083 TEST=tested on new and old impl on android side. Updated unit test. ==========
uploaded new patch. PTAL.
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
https://codereview.chromium.org/2189073003/diff/120001/components/exo/wayland... File components/exo/wayland/server.cc (left): https://codereview.chromium.org/2189073003/diff/120001/components/exo/wayland... components/exo/wayland/server.cc:1043: WaylandDisplayObserver(const display::Display& display, On 2016/07/29 at 19:27:03, oshima wrote: > On 2016/07/29 16:03:51, reveman wrote: > > this code was structured this way so that WaylandDisplayObserver class would > > have proper support for multiple displays and that limitation was kept outside > > this class. I'd prefer to keep it that way. Is there an important reason for > > changing it in this patch? > > It's simply wrong to keep the display id because primary display isn't persistent thing. > It's nothing to do with multi display. (You can plug in your laptop to external display, > close the lid, then the primary display switches to the external display, which has different id) So this code currently reports events for what is the primary display at the time the wl_output instance was created, right? I'm not sure what is more correct as the use of primary display is wrong in the first place. Sounds like before we have proper multi-display mode it would probably be less buggy to just have all exo code pick a display at startup and then use that for everything. Anyhow, I don't fully understand these display observer related changes and would prefer if this was saved for another patch after we had a chance to chat offline. Is that possible? https://codereview.chromium.org/2189073003/diff/140001/components/exo/shell_s... File components/exo/shell_surface.h (right): https://codereview.chromium.org/2189073003/diff/140001/components/exo/shell_s... components/exo/shell_surface.h:223: FRIEND_TEST_ALL_PREFIXES(ShellSurfaceTest, ShadowStartMaximized); nit: it would be nice to not start poking into the private implementation details in tests as when we have too much of that I think refactoring becomes hard and turns into an exercise in rewriting tests instead rewriting implementation logic.. can we test this shadow overlay logic in some other way? maybe check if the bottom most child is opaque and the size of the shadow?
https://codereview.chromium.org/2189073003/diff/120001/components/exo/wayland... File components/exo/wayland/server.cc (left): https://codereview.chromium.org/2189073003/diff/120001/components/exo/wayland... components/exo/wayland/server.cc:1043: WaylandDisplayObserver(const display::Display& display, On 2016/08/01 16:19:22, reveman wrote: > On 2016/07/29 at 19:27:03, oshima wrote: > > On 2016/07/29 16:03:51, reveman wrote: > > > this code was structured this way so that WaylandDisplayObserver class would > > > have proper support for multiple displays and that limitation was kept > outside > > > this class. I'd prefer to keep it that way. Is there an important reason for > > > changing it in this patch? > > > > It's simply wrong to keep the display id because primary display isn't > persistent thing. > > It's nothing to do with multi display. (You can plug in your laptop to > external display, > > close the lid, then the primary display switches to the external display, > which has different id) > > So this code currently reports events for what is the primary display at the > time the wl_output instance was created, right? Yes, and that is wrong. That display may not even exist when OnDisplayMetricsChanged. > I'm not sure what is more > correct as the use of primary display is wrong in the first place. Sounds like > before we have proper multi-display mode it would probably be less buggy to just > have all exo code pick a display at startup and then use that for everything. > Anyhow, I don't fully understand these display observer related changes and > would prefer if this was saved for another patch after we had a chance to chat > offline. Is that possible? I can move it to another patch, but it has to be fixed regardless of multidisplay support. It is more buggy even without it. For example, this will stop working once you enter docked mode (or exit the docked mode), which still uses single display.
Patchset #8 (id:160001) has been deleted
Patchset #8 (id:180001) has been deleted
Patchset #8 (id:200001) has been deleted
Patchset #8 (id:220001) has been deleted
The CQ bit was checked by oshima@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
separated primary display change per offline discussion. PTAL
lgtm
The CQ bit was checked by oshima@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
The CQ bit was checked by oshima@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Message was sent while issue was closed.
Description was changed from ========== Add configuration_changed event and set_background_opacity request. * remote shell API version is updated to 9. * Send the current primary display info because primary display is dynamic and can change or even go away. * This also fixed a bug where a underlay wasn't created when it started maximized. BUG=632083 TEST=tested on new and old impl on android side. Updated unit test. ========== to ========== Add configuration_changed event and set_background_opacity request. * remote shell API version is updated to 9. * Send the current primary display info because primary display is dynamic and can change or even go away. * This also fixed a bug where a underlay wasn't created when it started maximized. BUG=632083 TEST=tested on new and old impl on android side. Updated unit test. ==========
Message was sent while issue was closed.
Committed patchset #9 (id:260001)
Message was sent while issue was closed.
Description was changed from ========== Add configuration_changed event and set_background_opacity request. * remote shell API version is updated to 9. * Send the current primary display info because primary display is dynamic and can change or even go away. * This also fixed a bug where a underlay wasn't created when it started maximized. BUG=632083 TEST=tested on new and old impl on android side. Updated unit test. ========== to ========== Add configuration_changed event and set_background_opacity request. * remote shell API version is updated to 9. * Send the current primary display info because primary display is dynamic and can change or even go away. * This also fixed a bug where a underlay wasn't created when it started maximized. BUG=632083 TEST=tested on new and old impl on android side. Updated unit test. Committed: https://crrev.com/80d20b2f6bc5a6aa8e0caa37f517aef783d3186d Cr-Commit-Position: refs/heads/master@{#409089} ==========
Message was sent while issue was closed.
Patchset 9 (id:??) landed as https://crrev.com/80d20b2f6bc5a6aa8e0caa37f517aef783d3186d Cr-Commit-Position: refs/heads/master@{#409089} |