Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2500973002:
Converts test_wm to use aura (Closed)
DescriptionConverts test_wm to use aura
BUG=664625
TEST=covered by tests
R=msw@chromium.org
Committed: https://crrev.com/bec8c81f5fa63932e2c95d91d800b7486f40ab0d
Cr-Commit-Position: refs/heads/master@{#434203}
Patch Set 1 #Patch Set 2 : cleanup #
Total comments: 6
Patch Set 3 : Feedback and fix from Sadrul #Patch Set 4 : merge 2 trunk #Patch Set 5 : fix bad remove #
Total comments: 8
Patch Set 6 : delete cant be used #
Total comments: 1
Patch Set 7 : feedback #
Total comments: 2
Patch Set 8 : oopsie #
Total comments: 3
Patch Set 9 : ! #Patch Set 10 : merge #Patch Set 11 : update args #Patch Set 12 : fix #Patch Set 13 : merge #Patch Set 14 : tweak #
Total comments: 1
Patch Set 15 : reset root_ and disable #Patch Set 16 : nuke gl #Patch Set 17 : no new args #
Total comments: 5
Patch Set 18 : reference bug #
Messages
Total messages: 71 (37 generated)
lgtm with nits and a q. https://codereview.chromium.org/2500973002/diff/20001/services/ui/test_wm/tes... File services/ui/test_wm/test_wm.cc (right): https://codereview.chromium.org/2500973002/diff/20001/services/ui/test_wm/tes... services/ui/test_wm/test_wm.cc:54: ui::InitializeContextFactoryForTests(enable_pixel_output)); q: Should something in this file call TerminateContextFactoryForTests? https://codereview.chromium.org/2500973002/diff/20001/services/ui/test_wm/tes... services/ui/test_wm/test_wm.cc:57: base::MakeUnique<aura::WindowTreeClient>(this, this, nullptr); optional nit: drop nullptr arg, it's the default https://codereview.chromium.org/2500973002/diff/20001/services/ui/test_wm/tes... services/ui/test_wm/test_wm.cc:156: std::unique_ptr<::wm::WMState> wm_state_; nit: avoid unique_ptr? https://codereview.chromium.org/2500973002/diff/20001/services/ui/test_wm/tes... services/ui/test_wm/test_wm.cc:158: std::unique_ptr<aura::test::TestFocusClient> focus_client_; nit: avoid unique_ptr?
The CQ bit was checked by sky@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...
sky@chromium.org changed reviewers: + sadrul@chromium.org
+sadrul I this is finally ready for re-review. I had to add some code from Sadrul to get tests working correctly. Running views_mus_unittests also uncovered a bug in WindowTreeClient. Specifically when the server told the client a window was deleted the client would schedule deletion again with the server. In this case the deletion would fail (because the window was already deleted on the server) and the client would hit a CHECK in in_flight_change. This was crashing test_wm and causing tests to wedge. You'll notice I'm adding logging to window_tree in this patch. I think this is going to prove helpful for tracking down other similar issues and so I'm leading it in (DVLOG). Take another look? https://codereview.chromium.org/2500973002/diff/20001/services/ui/test_wm/tes... File services/ui/test_wm/test_wm.cc (right): https://codereview.chromium.org/2500973002/diff/20001/services/ui/test_wm/tes... services/ui/test_wm/test_wm.cc:54: ui::InitializeContextFactoryForTests(enable_pixel_output)); On 2016/11/14 19:23:10, msw wrote: > q: Should something in this file call TerminateContextFactoryForTests? Done. https://codereview.chromium.org/2500973002/diff/20001/services/ui/test_wm/tes... services/ui/test_wm/test_wm.cc:57: base::MakeUnique<aura::WindowTreeClient>(this, this, nullptr); On 2016/11/14 19:23:10, msw wrote: > optional nit: drop nullptr arg, it's the default Done.
The CQ bit was checked by sky@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...
still lgtm with nits and minor comments. https://codereview.chromium.org/2500973002/diff/80001/services/ui/test_wm/tes... File services/ui/test_wm/test_wm.cc (right): https://codereview.chromium.org/2500973002/diff/80001/services/ui/test_wm/tes... services/ui/test_wm/test_wm.cc:50: ui::TerminateContextFactoryForTests(); Is this still needed? I don't see InitializeContextFactoryForTests anymore. (perhaps this isn't needed now that you're using MusContextFactory?) https://codereview.chromium.org/2500973002/diff/80001/services/ui/ws/window_t... File services/ui/ws/window_tree.cc (right): https://codereview.chromium.org/2500973002/diff/80001/services/ui/ws/window_t... services/ui/ws/window_tree.cc:310: DVLOG(2) << "removing window from parent client=" << id_ q: use level 3 to avoid level-2 spam for expected behavior? ditto below https://codereview.chromium.org/2500973002/diff/80001/services/ui/ws/window_t... services/ui/ws/window_tree.cc:311: << " local window_id= " << window_id.id << " glocal window_id=" q: glocal? ditto below https://codereview.chromium.org/2500973002/diff/80001/ui/aura/mus/window_port... File ui/aura/mus/window_port_mus.cc (right): https://codereview.chromium.org/2500973002/diff/80001/ui/aura/mus/window_port... ui/aura/mus/window_port_mus.cc:37: const WindowTreeClient::Origin origin = nit: maybe comment here since this is slightly sublte? Something like "Check for a scheduled DESTROY change from the server, so the client can avoid cyclically scheduling a DELETE_WINDOW change on the server."? https://codereview.chromium.org/2500973002/diff/100001/ui/aura/mus/window_por... File ui/aura/mus/window_port_mus.cc (right): https://codereview.chromium.org/2500973002/diff/100001/ui/aura/mus/window_por... ui/aura/mus/window_port_mus.cc:38: RemoveChangeByTypeAndData(ServerChangeType::DESTROY, ServerChangeData()) aside: too bad we have two change type enums with skewed names
The CQ bit was checked by sky@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from msw@chromium.org Link to the patchset: https://codereview.chromium.org/2500973002/#ps120001 (title: "feedback")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
https://codereview.chromium.org/2500973002/diff/80001/services/ui/test_wm/tes... File services/ui/test_wm/test_wm.cc (right): https://codereview.chromium.org/2500973002/diff/80001/services/ui/test_wm/tes... services/ui/test_wm/test_wm.cc:50: ui::TerminateContextFactoryForTests(); On 2016/11/17 21:26:14, msw wrote: > Is this still needed? I don't see InitializeContextFactoryForTests anymore. > (perhaps this isn't needed now that you're using MusContextFactory?) Done. https://codereview.chromium.org/2500973002/diff/80001/services/ui/ws/window_t... File services/ui/ws/window_tree.cc (right): https://codereview.chromium.org/2500973002/diff/80001/services/ui/ws/window_t... services/ui/ws/window_tree.cc:310: DVLOG(2) << "removing window from parent client=" << id_ On 2016/11/17 21:26:14, msw wrote: > q: use level 3 to avoid level-2 spam for expected behavior? ditto below Done. https://codereview.chromium.org/2500973002/diff/80001/services/ui/ws/window_t... services/ui/ws/window_tree.cc:311: << " local window_id= " << window_id.id << " glocal window_id=" On 2016/11/17 21:26:15, msw wrote: > q: glocal? ditto below Done. https://codereview.chromium.org/2500973002/diff/80001/ui/aura/mus/window_port... File ui/aura/mus/window_port_mus.cc (right): https://codereview.chromium.org/2500973002/diff/80001/ui/aura/mus/window_port... ui/aura/mus/window_port_mus.cc:37: const WindowTreeClient::Origin origin = On 2016/11/17 21:26:15, msw wrote: > nit: maybe comment here since this is slightly sublte? Something like "Check for > a scheduled DESTROY change from the server, so the client can avoid cyclically > scheduling a DELETE_WINDOW change on the server."? I added a comment indicating why DESTROY means it originated from the server.
slgtm with a q https://codereview.chromium.org/2500973002/diff/120001/services/ui/ws/window_... File services/ui/ws/window_tree.cc (right): https://codereview.chromium.org/2500973002/diff/120001/services/ui/ws/window_... services/ui/ws/window_tree.cc:311: << " local window_id= " << window_id.id << " local window_id=" Are both really local? Is the 2nd global? (ditto below)
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: blimp_linux_dbg on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/blimp_linux_dbg...) chromeos_x86-generic_chromium_compile_only_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_x86-ge...) linux_chromium_asan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...) linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
https://codereview.chromium.org/2500973002/diff/120001/services/ui/ws/window_... File services/ui/ws/window_tree.cc (right): https://codereview.chromium.org/2500973002/diff/120001/services/ui/ws/window_... services/ui/ws/window_tree.cc:311: << " local window_id= " << window_id.id << " local window_id=" On 2016/11/17 22:27:27, msw wrote: > Are both really local? Is the 2nd global? (ditto below) Oopsie.
lgtm https://codereview.chromium.org/2500973002/diff/140001/services/ui/test_wm/te... File services/ui/test_wm/test_wm.cc (right): https://codereview.chromium.org/2500973002/diff/140001/services/ui/test_wm/te... services/ui/test_wm/test_wm.cc:40: TestWM() { gl::GLSurfaceTestSupport::InitializeOneOff(); } Do you need to initialize gl here?
The CQ bit was checked by sky@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from msw@chromium.org, sadrul@chromium.org Link to the patchset: https://codereview.chromium.org/2500973002/#ps160001 (title: "!")
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
Try jobs failed on following builders: ios-simulator on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...) mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...) mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)
The CQ bit was checked by sky@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from msw@chromium.org, sadrul@chromium.org Link to the patchset: https://codereview.chromium.org/2500973002/#ps180001 (title: "merge")
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
Try jobs failed on following builders: linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
The CQ bit was checked by sky@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...
https://codereview.chromium.org/2500973002/diff/140001/services/ui/test_wm/te... File services/ui/test_wm/test_wm.cc (right): https://codereview.chromium.org/2500973002/diff/140001/services/ui/test_wm/te... services/ui/test_wm/test_wm.cc:40: TestWM() { gl::GLSurfaceTestSupport::InitializeOneOff(); } On 2016/11/18 01:03:53, sadrul wrote: > Do you need to initialize gl here? I'm not sure. Should I be? I did update the patch so that --override-use-gl-with-osmesa-for-tests is added as an arg to views_mus_unittests and views_mus_interactive_ui_tests. Take another look?
On 2016/11/18 05:11:06, sky wrote: > https://codereview.chromium.org/2500973002/diff/140001/services/ui/test_wm/te... > File services/ui/test_wm/test_wm.cc (right): > > https://codereview.chromium.org/2500973002/diff/140001/services/ui/test_wm/te... > services/ui/test_wm/test_wm.cc:40: TestWM() { > gl::GLSurfaceTestSupport::InitializeOneOff(); } > On 2016/11/18 01:03:53, sadrul wrote: > > Do you need to initialize gl here? > > I'm not sure. Should I be? I did update the patch so that > --override-use-gl-with-osmesa-for-tests is added as an arg to > views_mus_unittests and views_mus_interactive_ui_tests. Take another look? If I do need to initialize gl, what's the command?
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
The CQ bit was checked by sky@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: Try jobs failed on following builders: linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
I believe I've resoled all the issues blocking this and am going to try to land again. The only thing interesting I'm adding to this patch is disabling a test for mus and aura-mus. The test uses a death assert, which forks the process and doesn't work well with mus.
The CQ bit was checked by sky@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from msw@chromium.org, sadrul@chromium.org Link to the patchset: https://codereview.chromium.org/2500973002/#ps260001 (title: "tweak")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
On 2016/11/22 04:27:10, sky wrote: > I believe I've resoled all the issues blocking this and am going to try to land > again. The only thing interesting I'm adding to this patch is disabling a test > for mus and aura-mus. The test uses a death assert, which forks the process and > doesn't work well with mus. Ben (bruthig@) has a fix for the death test: https://codereview.chromium.org/2514293003/
On 2016/11/22 04:33:11, sadrul wrote: > On 2016/11/22 04:27:10, sky wrote: > > I believe I've resoled all the issues blocking this and am going to try to > land > > again. The only thing interesting I'm adding to this patch is disabling a test > > for mus and aura-mus. The test uses a death assert, which forks the process > and > > doesn't work well with mus. > > Ben (bruthig@) has a fix for the death test: > https://codereview.chromium.org/2514293003/ I have left a comment in the CL to re-enable the test with the fix. For now, I think this CL can leave the test disabled to not block in CQ.
Thanks! On Mon, Nov 21, 2016 at 8:34 PM, <sadrul@chromium.org> wrote: > On 2016/11/22 04:33:11, sadrul wrote: >> On 2016/11/22 04:27:10, sky wrote: >> > I believe I've resoled all the issues blocking this and am going to try >> > to >> land >> > again. The only thing interesting I'm adding to this patch is disabling >> > a > test >> > for mus and aura-mus. The test uses a death assert, which forks the >> > process >> and >> > doesn't work well with mus. >> >> Ben (bruthig@) has a fix for the death test: >> https://codereview.chromium.org/2514293003/ > > I have left a comment in the CL to re-enable the test with the fix. For now, > I > think this CL can leave the test disabled to not block in CQ. > > https://codereview.chromium.org/2500973002/ -- You received this message because you are subscribed to the Google Groups "Chromium-reviews" group. To unsubscribe from this group and stop receiving emails from it, send an email to chromium-reviews+unsubscribe@chromium.org.
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
bruthig@chromium.org changed reviewers: + bruthig@chromium.org
Just adding myself to CC to watch for when this lands.
still lgtm with a q https://codereview.chromium.org/2500973002/diff/260001/services/ui/test_wm/te... File services/ui/test_wm/test_wm.cc (right): https://codereview.chromium.org/2500973002/diff/260001/services/ui/test_wm/te... services/ui/test_wm/test_wm.cc:146: void OnWmDisplayRemoved(aura::WindowTreeHostMus* window_tree_host) override { Should this also set |root_| to null? Maybe call window_manager_client_->RemoveActivationParent(root_); Maybe more?
The CQ bit was checked by sky@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was checked by sky@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: Try jobs failed on following builders: linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
fsamuel@chromium.org changed reviewers: + fsamuel@chromium.org
https://codereview.chromium.org/2500973002/diff/140001/services/ui/test_wm/te... File services/ui/test_wm/test_wm.cc (right): https://codereview.chromium.org/2500973002/diff/140001/services/ui/test_wm/te... services/ui/test_wm/test_wm.cc:40: TestWM() { gl::GLSurfaceTestSupport::InitializeOneOff(); } On 2016/11/18 05:11:06, sky wrote: > On 2016/11/18 01:03:53, sadrul wrote: > > Do you need to initialize gl here? > > I'm not sure. Should I be? I did update the patch so that > --override-use-gl-with-osmesa-for-tests is added as an arg to > views_mus_unittests and views_mus_interactive_ui_tests. Take another look? I wonder if this is happening too late? This usually seems to get called very early in the TestSuite: https://cs.chromium.org/chromium/src/ash/test/test_suite.cc?sq=package:chromi...
On 2016/11/23 00:39:54, Fady Samuel wrote: > https://codereview.chromium.org/2500973002/diff/140001/services/ui/test_wm/te... > File services/ui/test_wm/test_wm.cc (right): > > https://codereview.chromium.org/2500973002/diff/140001/services/ui/test_wm/te... > services/ui/test_wm/test_wm.cc:40: TestWM() { > gl::GLSurfaceTestSupport::InitializeOneOff(); } > On 2016/11/18 05:11:06, sky wrote: > > On 2016/11/18 01:03:53, sadrul wrote: > > > Do you need to initialize gl here? > > > > I'm not sure. Should I be? I did update the patch so that > > --override-use-gl-with-osmesa-for-tests is added as an arg to > > views_mus_unittests and views_mus_interactive_ui_tests. Take another look? > > I wonder if this is happening too late? This usually seems to get called very > early in the TestSuite: > > https://cs.chromium.org/chromium/src/ash/test/test_suite.cc?sq=package:chromi... Ok, I think I got it. The inputmethod test is flakey, so I'm disabling it (will add a comment and file a bug). Apparently using --override-us-gl-with-osmesa-for-tests and initializing gl contributed to the problem. Sadrul, could you take another look?
lgtm https://codereview.chromium.org/2500973002/diff/320001/services/ui/service.cc File services/ui/service.cc (right): https://codereview.chromium.org/2500973002/diff/320001/services/ui/service.cc... services/ui/service.cc:153: ui::SetDefaultX11ErrorHandlers(); I don't think this has an effect on ozone builds. https://codereview.chromium.org/2500973002/diff/320001/ui/views/mus/input_met... File ui/views/mus/input_method_mus_unittest.cc (right): https://codereview.chromium.org/2500973002/diff/320001/ui/views/mus/input_met... ui/views/mus/input_method_mus_unittest.cc:80: TEST_F(InputMethodMusTest, DISABLED_DispatchKeyEvent) { Are there logs/stack-traces from this failing test?
Description was changed from ========== Converts test_wm to use aura BUG=664625 TEST=covered by tests R=msw@chromium.org ========== to ========== Converts test_wm to use aura BUG=664625,668181 TEST=covered by tests R=msw@chromium.org ==========
https://codereview.chromium.org/2500973002/diff/320001/services/ui/service.cc File services/ui/service.cc (right): https://codereview.chromium.org/2500973002/diff/320001/services/ui/service.cc... services/ui/service.cc:153: ui::SetDefaultX11ErrorHandlers(); On 2016/11/23 06:19:53, sadrul wrote: > I don't think this has an effect on ozone builds. It doesn't. That's why it's in the USE_X11 ifdef. Or am I missing something? https://codereview.chromium.org/2500973002/diff/320001/ui/views/mus/input_met... File ui/views/mus/input_method_mus_unittest.cc (right): https://codereview.chromium.org/2500973002/diff/320001/ui/views/mus/input_met... ui/views/mus/input_method_mus_unittest.cc:80: TEST_F(InputMethodMusTest, DISABLED_DispatchKeyEvent) { On 2016/11/23 06:19:53, sadrul wrote: > Are there logs/stack-traces from this failing test? I filed a bug on it and add a reference here. Bug is 668181. See it for details as to why I think it deadlocks.
The CQ bit was checked by sky@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from msw@chromium.org, sadrul@chromium.org Link to the patchset: https://codereview.chromium.org/2500973002/#ps340001 (title: "reference bug")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
https://codereview.chromium.org/2500973002/diff/320001/services/ui/service.cc File services/ui/service.cc (right): https://codereview.chromium.org/2500973002/diff/320001/services/ui/service.cc... services/ui/service.cc:153: ui::SetDefaultX11ErrorHandlers(); On 2016/11/23 16:22:11, sky wrote: > On 2016/11/23 06:19:53, sadrul wrote: > > I don't think this has an effect on ozone builds. > > It doesn't. That's why it's in the USE_X11 ifdef. Or am I missing something? Nope. Just wanted to point out that this doesn't affect ozone-x11 either.
We run the ui service in the x11 non-ozone config. Maybe we shouldn't? On Wed, Nov 23, 2016 at 8:27 AM, <sadrul@chromium.org> wrote: > > https://codereview.chromium.org/2500973002/diff/320001/services/ui/service.cc > File services/ui/service.cc (right): > > https://codereview.chromium.org/2500973002/diff/320001/services/ui/service.cc... > services/ui/service.cc:153: ui::SetDefaultX11ErrorHandlers(); > On 2016/11/23 16:22:11, sky wrote: >> On 2016/11/23 06:19:53, sadrul wrote: >> > I don't think this has an effect on ozone builds. >> >> It doesn't. That's why it's in the USE_X11 ifdef. Or am I missing > something? > > Nope. Just wanted to point out that this doesn't affect ozone-x11 > either. > > https://codereview.chromium.org/2500973002/ -- You received this message because you are subscribed to the Google Groups "Chromium-reviews" group. To unsubscribe from this group and stop receiving emails from it, send an email to chromium-reviews+unsubscribe@chromium.org.
CQ is committing da patch.
Bot data: {"patchset_id": 340001, "attempt_start_ts": 1479918143177280,
"parent_rev": "124f3710e2e2a6fca7c1147dde726fabcdd73040", "commit_rev":
"513c321c8a223390dd1a807ca52e1cf259b5f97d"}
Message was sent while issue was closed.
Committed patchset #18 (id:340001)
Message was sent while issue was closed.
Description was changed from ========== Converts test_wm to use aura BUG=664625 TEST=covered by tests R=msw@chromium.org ========== to ========== Converts test_wm to use aura BUG=664625 TEST=covered by tests R=msw@chromium.org Committed: https://crrev.com/bec8c81f5fa63932e2c95d91d800b7486f40ab0d Cr-Commit-Position: refs/heads/master@{#434203} ==========
Message was sent while issue was closed.
Patchset 18 (id:??) landed as https://crrev.com/bec8c81f5fa63932e2c95d91d800b7486f40ab0d Cr-Commit-Position: refs/heads/master@{#434203} |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
