Views on Windows: Force NativeWidgetAura for shadow_elevation Widgets

On Windows, Widgets with shadow_elevation specified are currently drawn
incorrectly. This is because we spawn a native top-level window, which
ignores shadow_elevation.

This is to be expected, since the Windows window manager has no concept
of Material shadow elevation.

This CL forces those Widgets with shadow_elevation to use an Aura
non-toplevel window.

The caveat is that these widgets are now clipped to the root browser
window. (It can't be bigger.) But it has the benefits of being:

 1. Low maintainence
 2. Click-through shadow
 3. Proper hit testing

Bug: 823535, 838667
Change-Id: I008ab64d0f3b7c2811d11ac94f00d041c45bf730
Reviewed-on: https://chromium-review.googlesource.com/1028833
Commit-Queue: Tommy Li <tommycli@chromium.org>
Reviewed-by: Peter Kasting <pkasting@chromium.org>
Cr-Commit-Position: refs/heads/master@{#555267}

chrome/browser/ui/views/chrome_views_delegate_win.cc

@@ -121,7 +121,15 @@ views::NativeWidget* ChromeViewsDelegate::CreateNativeWidget(
           ? NativeWidgetType::NATIVE_WIDGET_AURA
           : NativeWidgetType::DESKTOP_NATIVE_WIDGET_AURA;
 
-  if (!ui::win::IsAeroGlassEnabled()) {
+  if (params->shadow_type == views::Widget::InitParams::SHADOW_TYPE_DROP &&
+      params->shadow_elevation.has_value()) {
+    // If the window defines an elevation based shadow in the Widget
+    // initialization parameters, force the use of a non toplevel window,
+    // as the native window manager has no concept of elevation based shadows.
+    // TODO: This may no longer be needed if we get proper elevation-based
+    // shadows on toplevel windows. See https://crbug.com/838667.
+    native_widget_type = NativeWidgetType::NATIVE_WIDGET_AURA;
+  } else if (!ui::win::IsAeroGlassEnabled()) {
     // If we don't have composition (either because Glass is not enabled or
     // because it was disabled at the command line), anything that requires
     // transparency will be broken with a toplevel window, so force the use of