Chrome Version       : 55.0.2883.11

Signature is:

views::Widget* CreateBrowserModalDialogViews(views::DialogDelegate* dialog,
                                             gfx::NativeWindow parent);

What steps will reproduce the problem?
1. Call constrained_window::CreateBrowserModalDialogViews(new WindowModalDialog(), nullptr);

What is the expected result? What happens instead of that?

Something should complain! But nothing does.

CreateBrowserModalDialogViews(..) has 
  DCHECK_NE(ui::MODAL_TYPE_CHILD, dialog->GetModalType());
  DCHECK_NE(ui::MODAL_TYPE_NONE, dialog->GetModalType());

so this ModalType() must be MODAL_TYPE_WINDOW or MODAL_TYPE_SYSTEM. A null parent may be sensible for MODAL_TYPE_SYSTEM (although there is no |context| which would have confused Metro mode).

However, a null parent is also allowed for MODAL_TYPE_WINDOW. But that doesn't make sense.

Current NativeWidget logic allows this, and the Widget falls back to a non-modal window. This effectively ignores the WidgetDelegate::ModalType() request, which might not be what the dialog wants. If the parent is null, the client code probably shouldn't call CreateBrowserModalDialogViews at all. But currently this fallback allows some things to work. For example, extension "permissions need upgrading" dialogs when an extension is launched from a Windows (or Linux/Mac) Desktop shortcut, or an app that has been pinned to the ChromeOS shelf.

See also http://crbug.com/647574#c9 and https://codereview.chromium.org/2415053002