feat(material-experimental): MDC-based version of dialog

[devversion]

Initial version of the MDC-based dialog.

[crisbeto]

It seems like all the places where this is used are stubbing out the interface for Angular's AnimationEvent. Since this is an internal event, couldn't we change it to something that is more convenient to pass around?

[devversion]

I don't see how this can be made more convenient. From my perspective, this interface is easy to use and understand. It's not too coupled to Angular's AnimationEvent since it contains a specific state for the dialog (e.g. closed, closing and more).

Happy to change to something else if you have any ideas.

[crisbeto]

LGTM

[mmalerba]

Do we need to add an instance to the kitchen sink app too?

Hopefully @jelbourn can take a look at this next week. He's a lot more familiar with the dialog than I am

[devversion]

@mmalerba Addressed feedback. Thanks! Please have another look when you get a chance.

[mmalerba]

LGTM, but @jelbourn still needs to take a look

[devversion]

@jelbourn Addressed feedback. Please have another look when you get a chance.

[jelbourn]

LGTM

We can change the way it does padding in a follow-up

[andrewseguin]

Due to the focus changes (and thus some new triggered change detection changes), it's possible for MatDialogClose to run its ngOnInit before the dialog finishes initializes everything. Therefore, this.dialogRef could be left undefined.

If _onButtonClick is called during this, an error will be thrown because this.dialogRef isn't present. To fix, let's change MatDialogRef._onButtonClick (https://github.com/angular/components/blob/master/src/material/dialog/dialog-content-directives.ts#L36) to the following:

  _onButtonClick(event: MouseEvent) {
    if (!this.dialogRef) {
      this.dialogRef = getClosestDialog(this._elementRef, this._dialog.openDialogs)!;
    }

    // Determinate the focus origin using the click event, because using the FocusMonitor will
    // result in incorrect origins. Most of the time, close buttons will be auto focused in the
    // dialog, and therefore clicking the button won't result in a focus change. This means that
    // the FocusMonitor won't detect any origin change, and will always output `program`.
    _closeDialogVia(this.dialogRef,
        event.screenX === 0 && event.screenY === 0 ? 'keyboard' : 'mouse', this.dialogResult);
  }

[andrewseguin]

We're close to getting this one in - mind fixing that browserstack test failure?

[devversion]

This is finally green! While fixing tests in Safari and Firefox I found that we leak providers and styles between tests. Fixing this reduced average CI time for Browserstack from 30min to 5min! Previously browsers on BS and SL were close to crash (and sometimes did) due to too many style elements in the DOM (and too many providers being retained).

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}