Using NativeCursorManagerAshMus for MASH as well as MUS allows DragDropControllerTest.* to pass, but I don't know whether that is the correct solution? Building chrome to see what happens next.

Worth noting: Shell::SetCursorCompositingEnabled has "// TODO: needs to work in mash.  http://crbug.com/705592 " but  issue 705592  is marked as a duplicate of  issue 729798  which is marked fixed.

Hopefully helpful braindump:

The reason to use NativeCursorManager in classic as well as mus is because there's a single aura::Window tree with an associated window manager, where there is a single cursor set on the display and all windows are part of the same trusted tree.

This isn't the case in mash. In mash, each ui Window has its own cursor state (and its own non-client cursor state set by the window manager). Mus becomes responsible for setting the logical cursor state from the window at the cursor location. You don't want arbitrary apps to be able to change the cursor state. 

The code for the drag operations that are managed by the ui server is in //services/ui/ws/drag_controller.cc.

Ah, I see. We're not actually instantiating drag_drop_controller_ for MASH ("In mash drag and drop is handled by mus.").

So, it seems to me that the thing to do is permanently exclude DragDropControllerTest from ash_unittests in mash builds.

James, what's the right way to do that? Can we omit them from BUILD.gn? That seems preferable to using an #ifdef in the unit test itself.

> We're not actually instantiating drag_drop_controller_ for MASH

Correct.

Mash is a runtime option, so the builds are identical. We can't use BUILD.gn.

Policy for ash unittests:
* If the test is irrelevant to mash, add a check for Shell::GetAshConfig() == Config::MASH at the start of the test and early exit.
* If the test should work eventually in mash, disable it via the ash_unittests_mash.filter file.

erg, 2 questions:
1. Will we ever want a CursorManager implementation for mash? Right now lots of tests crash because they try to access Shell::cursor_manager().
2. Will we ever use DragDropController?

We will never use DragDropController, and I think we'll never want a CursorManager, as the model of a single global cursor which CursorManager is built around is no longer right.

Hmm, currently we appear to have a mix of code that tests for cursor_manager() and code that does not. I find this confusing and error prone.

I think it may make sense to replace cursor_manager() with something like GetGlobalCursorManager() since it is sometimes null, and maybe DCHECK(!mash). At minimum we need a comment.

Fortunately we don't appear to have a global accesssor for DragDropController.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a866fca776e66f0e1e81a15cd1dd6e2113dbcd5f

commit a866fca776e66f0e1e81a15cd1dd6e2113dbcd5f
Author: Steven Bennetts <stevenjb@chromium.org>
Date: Tue Nov 07 19:39:35 2017

Mash: Skip DragDropControllerTest

We do not instantiate DragDropController in mash.

Bug:  780196 
Change-Id: Ieac9b773d53467f7906ef249093a7dc477178cf2
Reviewed-on: https://chromium-review.googlesource.com/750044
Reviewed-by: James Cook <jamescook@chromium.org>
Reviewed-by: Elliot Glaysher <erg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#514545}
[modify] https://crrev.com/a866fca776e66f0e1e81a15cd1dd6e2113dbcd5f/ash/drag_drop/drag_drop_controller_unittest.cc
[modify] https://crrev.com/a866fca776e66f0e1e81a15cd1dd6e2113dbcd5f/ash/shell.h
[modify] https://crrev.com/a866fca776e66f0e1e81a15cd1dd6e2113dbcd5f/testing/buildbot/filters/ash_unittests_mash.filter