This is .. tricky I think. content_browsertests does not have a way of bringing up ash, so I can't think of a straight-forward way for providing a real accelerated widget for the tests.

.. although it looks like if content_browsertests is using AuraTestHelper, then it should be setting things up correctly (i.e. a non-null window_manager_delegate_) [1]? So maybe we are not using AuraTestHelper, and we should? But even then, the test-delegate does not actually send the real accelerated widget back to the WindowTreeHostMus, so we would probably need to fix that too [2].

[1] https://cs.chromium.org/chromium/src/ui/aura/test/aura_test_helper.cc?type=cs&l=105
[2] https://cs.chromium.org/chromium/src/ui/aura/test/mus/test_window_manager_delegate.cc?type=cs&l=20

Can we do the same thing as the non-mus CrOS content_browsertests? I'd assume it has the same limitation on not including ash but it creates a real accelerated widget still.

As Sadrul says, we don't want mus_content_browsertests to have a dependency on ash, so it connects to mus using WindowTreeHostFactory. There is no window manager in this code. None-the-less mus creates a real accelerated widget:  https://chromium.googlesource.com/chromium/src/+/master/services/ui/ws/window_tree_host_factory.cc#29 . It doesn't look like this path notifies the client of the accelerated widget. Probably right thing is to add a WindowTreeHostClient interface that is used in this path and notified of the accelerated widget.

How urgent is this Kyle?

Not super high priority. I figured out why EGL wasn't working over CRD after upgrading to gLinux, so having OSMesa support isn't strictly necessary.

uses_real_accelerated_widget has been removed, and I believe we've also nuked OSMesa. So, I'm not sure there is anything to do here. I'm closing out, assuming there isn't. If I'm wrong, please reopen.