fix(ngForm): don't block submit when method=dialog

[dpogue]

When a form's method is set to "dialog" it does not post to a server but instead closes the nearest parent element. An action is not required.

https://html.spec.whatwg.org/multipage/forms.html#submit-dialog

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project, in which case you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.

---

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If you signed the CLA as a corporation, please let us know the company's name.

[dpogue]

I signed it!

[googlebot]

CLAs look good, thanks!

[Narretz]

Shocking support for that element: http://caniuse.com/#feat=dialog
But I don't think it'll hurt, as someone who uses method="dialog" will know what they're doing. There's still some work to do for this though:

• Add a test for this
• Add a line to the docs that says submit will not be blocked when method is set to dialog.

[Narretz]

What happens when the action attr is set and method is set to dialog?

[dpogue]

According to the spec, if method is dialog then it closes the dialog and stops further processing. The action attribute should be ignored by the browser in that case.

[Narretz]

What I meant is: if the action attribute is set and the method is set to dialog, your code change would not prevent the submit. Isn't !('action' in attr) || attr['method'] !== 'dialog' what we want?

[Narretz]

Ah, I think I misunderstood the purpose. I though it should block submit when the method is dialog, doh. Having the test really helps understanding what a change is about.

[dpogue]

I've added a test and updated the comments. I'm not sure that blocking submit when method="dialog" with an action is what we want? It should be up to the browser to handle that properly.

[Narretz]

Thanks for the test. Now that method="dialog" does not block submit anymore, I think we'd still want to have it call $commitViewValue and $setSubmitted on the form, right? Previously, it would set these only if the form wasn't sent to the server. Now the form isn't sent to the server, so I assume we still want that.