Migrate <cr-dialog> from PaperDialogBehavior to native <dialog>.

Migrate <cr-dialog> from PaperDialogBehavior to native <dialog>.

 - Make <cr-dialog> extend a native <dialog> element.
 - Modify <cr-dialog> API as follows
   Events renamed:
     'iron-overlay-closed' -> 'close'
     'iron-overlay-canceled' -> 'cancel'
     'iron-overlay-opened' -> No equivalent event. Can be added if it
     turns out to be necessary.
   Method rename: 'open()' -> 'showModal()'
   Attribute rename: 'opened' -> 'open'

Also since HTMLDialogElement#showModal() and HTMLDialogElement#close()
are stricter than equivalent PaperDialogBehavior methods, the following
<cr-dialog> behavioral changes are caused by this migration.

 1) Calling showModal() when the element is not in the DOM throws exception.
 2) Calling showModal()/close() when dialog is already opened/closed throws
    exception.

BUG=625332
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Committed: https://crrev.com/0501e1b4e707a2d7f4a0525f2f9b0b1ba2dac644
Cr-Commit-Position: refs/heads/master@{#408495}

[dpapad, 2016-07-25 22:18:30]

Description was changed from

==========
Migrate <cr-dialog> from PaperDialogBehavior to native <dialog>.

 - Make <cr-dialog> extend a native <dialog> element.
 - Modify <cr-dialog> API as follows
   'iron-overlay-closed' -> 'close'
   'iron-overlay-canceled' -> 'cancel'
   'iron-overlay-opened' -> No equivalent event. Can be added if it
   turns out to be necessary.
   'open()' -> 'showModal()'

Also since HTMLDialogElement#showModal() and HTMLDialogElement#close()
are stricter than equivalent PaperDialogBehavior methods, the following
<cr-dialog> behavioral changes are caused by this migration.

 1) Calling showModal() when the element is not in the DOM throws exception.
 2) Calling showModal()/close() when dialog is already opened/closed throws
    exception.

BUG=625332
==========

to

==========
Migrate <cr-dialog> from PaperDialogBehavior to native <dialog>.

 - Make <cr-dialog> extend a native <dialog> element.
 - Modify <cr-dialog> API as follows
   'iron-overlay-closed' -> 'close'
   'iron-overlay-canceled' -> 'cancel'
   'iron-overlay-opened' -> No equivalent event. Can be added if it
   turns out to be necessary.
   'open()' -> 'showModal()'

Also since HTMLDialogElement#showModal() and HTMLDialogElement#close()
are stricter than equivalent PaperDialogBehavior methods, the following
<cr-dialog> behavioral changes are caused by this migration.

 1) Calling showModal() when the element is not in the DOM throws exception.
 2) Calling showModal()/close() when dialog is already opened/closed throws
    exception.

BUG=625332
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation
==========

[dpapad, 2016-07-25 22:19:43]

Description was changed from

==========
Migrate <cr-dialog> from PaperDialogBehavior to native <dialog>.

 - Make <cr-dialog> extend a native <dialog> element.
 - Modify <cr-dialog> API as follows
   'iron-overlay-closed' -> 'close'
   'iron-overlay-canceled' -> 'cancel'
   'iron-overlay-opened' -> No equivalent event. Can be added if it
   turns out to be necessary.
   'open()' -> 'showModal()'

Also since HTMLDialogElement#showModal() and HTMLDialogElement#close()
are stricter than equivalent PaperDialogBehavior methods, the following
<cr-dialog> behavioral changes are caused by this migration.

 1) Calling showModal() when the element is not in the DOM throws exception.
 2) Calling showModal()/close() when dialog is already opened/closed throws
    exception.

BUG=625332
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation
==========

to

==========
Migrate <cr-dialog> from PaperDialogBehavior to native <dialog>.

 - Make <cr-dialog> extend a native <dialog> element.
 - Modify <cr-dialog> API as follows
   Events renamed:
     'iron-overlay-closed' -> 'close'
     'iron-overlay-canceled' -> 'cancel'
     'iron-overlay-opened' -> No equivalent event. Can be added if it
     turns out to be necessary.
   Method rename: 'open()' -> 'showModal()'
   Attribute rename: 'opened' -> 'open'

Also since HTMLDialogElement#showModal() and HTMLDialogElement#close()
are stricter than equivalent PaperDialogBehavior methods, the following
<cr-dialog> behavioral changes are caused by this migration.

 1) Calling showModal() when the element is not in the DOM throws exception.
 2) Calling showModal()/close() when dialog is already opened/closed throws
    exception.

BUG=625332
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation
==========

[dpapad, 2016-07-25 22:20:08]

The CQ bit was checked by dpapad@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-25 22:20:45]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[dpapad, 2016-07-25 23:01:16]

dpapad@chromium.org changed reviewers:
+ dbeam@chromium.org

[dpapad, 2016-07-25 23:01:17]

Per offline discussion, I merged the previous two <dialog> CLs
(https://codereview.chromium.org/2059723003 and
https://codereview.chromium.org/2170213002) to a single CL. Hopefully that makes
things easier.

[commit-bot: I haz the power, 2016-07-26 00:04:09]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-26 00:04:10]

Dry run: This issue passed the CQ dry run.

[dpapad, 2016-07-26 23:22:17]

Uploaded changes regarding populating the |returnValue| to allow listeners to
detect cancel from the 'close' event callback.

[Dan Beam, 2016-07-26 23:36:13]

looks pretty good to em

https://codereview.chromium.org/2180823004/diff/1/chrome/browser/resources/se...
File chrome/browser/resources/settings/bluetooth_page/bluetooth_device_dialog.js
(right):

https://codereview.chromium.org/2180823004/diff/1/chrome/browser/resources/se...
chrome/browser/resources/settings/bluetooth_page/bluetooth_device_dialog.js:357:
},
arguable nit: this public method should go above private methods

https://codereview.chromium.org/2180823004/diff/1/chrome/browser/resources/se...
File
chrome/browser/resources/settings/certificate_manager_page/ca_trust_edit_dialog.js
(right):

https://codereview.chromium.org/2180823004/diff/1/chrome/browser/resources/se...
chrome/browser/resources/settings/certificate_manager_page/ca_trust_edit_dialog.js:49:
return;
shouldn't we propagate trustInfo_ though?

https://codereview.chromium.org/2180823004/diff/1/chrome/browser/resources/se...
File
chrome/browser/resources/settings/clear_browsing_data_dialog/clear_browsing_data_dialog.html
(left):

https://codereview.chromium.org/2180823004/diff/1/chrome/browser/resources/se...
chrome/browser/resources/settings/clear_browsing_data_dialog/clear_browsing_data_dialog.html:166:
dialog-dismiss>$i18n{cancel}</paper-button>
are you sure you got all of these? what about dialog-confirm?

https://codereview.chromium.org/2180823004/diff/1/chrome/browser/resources/se...
File
chrome/browser/resources/settings/clear_browsing_data_dialog/clear_browsing_data_dialog.html
(right):

https://codereview.chromium.org/2180823004/diff/1/chrome/browser/resources/se...
chrome/browser/resources/settings/clear_browsing_data_dialog/clear_browsing_data_dialog.html:110:
<dialog is="cr-dialog" id="dialog"
with-backdrop="[[!showHistoryDeletionDialog_]]">
nit: 80 col wrap

https://codereview.chromium.org/2180823004/diff/1/ui/webui/resources/cr_eleme...
File ui/webui/resources/cr_elements/cr_dialog/cr_dialog.html (right):

https://codereview.chromium.org/2180823004/diff/1/ui/webui/resources/cr_eleme...
ui/webui/resources/cr_elements/cr_dialog/cr_dialog.html:90: }
i would argue that these should go on the top of the list of rules in this
<style> tag

https://codereview.chromium.org/2180823004/diff/20001/ui/webui/resources/cr_e...
File ui/webui/resources/cr_elements/cr_dialog/cr_dialog.js (right):

https://codereview.chromium.org/2180823004/diff/20001/ui/webui/resources/cr_e...
ui/webui/resources/cr_elements/cr_dialog/cr_dialog.js:9: * Additionally clients
can inspect the dialog's |returnValue| property inisde
inisde -> inside

https://codereview.chromium.org/2180823004/diff/20001/ui/webui/resources/cr_e...
ui/webui/resources/cr_elements/cr_dialog/cr_dialog.js:11: * where a truthy value
means it was not canceled, and a falsy value means it
where a truthy value means success, and a falsy value means it was canceled.

[dpapad, 2016-07-27 01:21:47]

https://codereview.chromium.org/2180823004/diff/1/chrome/browser/resources/se...
File chrome/browser/resources/settings/bluetooth_page/bluetooth_device_dialog.js
(right):

https://codereview.chromium.org/2180823004/diff/1/chrome/browser/resources/se...
chrome/browser/resources/settings/bluetooth_page/bluetooth_device_dialog.js:357:
},
On 2016/07/26 at 23:36:12, Dan Beam wrote:
> arguable nit: this public method should go above private methods

Done.

https://codereview.chromium.org/2180823004/diff/1/chrome/browser/resources/se...
File
chrome/browser/resources/settings/certificate_manager_page/ca_trust_edit_dialog.js
(right):

https://codereview.chromium.org/2180823004/diff/1/chrome/browser/resources/se...
chrome/browser/resources/settings/certificate_manager_page/ca_trust_edit_dialog.js:49:
return;
On 2016/07/26 at 23:36:12, Dan Beam wrote:
> shouldn't we propagate trustInfo_ though?

I ended up removing this completely, by making the test smarter such as it waits
for showModal() to be called before moving on to the next test (using
MutationObserver for the 'open' attribute). This is better because this code no
longer runs after the test that created this dialog has finished, instead it
runs as part of the test.

https://codereview.chromium.org/2180823004/diff/1/chrome/browser/resources/se...
File
chrome/browser/resources/settings/clear_browsing_data_dialog/clear_browsing_data_dialog.html
(left):

https://codereview.chromium.org/2180823004/diff/1/chrome/browser/resources/se...
chrome/browser/resources/settings/clear_browsing_data_dialog/clear_browsing_data_dialog.html:166:
dialog-dismiss>$i18n{cancel}</paper-button>
On 2016/07/26 at 23:36:12, Dan Beam wrote:
> are you sure you got all of these? what about dialog-confirm?

I had missed a dialog-confirm occurrence in
site_settings/site_data_details_dialog.html, updated now (guessing it is not
covered by tests). I verified that it works manually, but also discovered that
it throws a runtime exception even without my changes in some cases (will file
bug).

https://codereview.chromium.org/2180823004/diff/1/chrome/browser/resources/se...
File
chrome/browser/resources/settings/clear_browsing_data_dialog/clear_browsing_data_dialog.html
(right):

https://codereview.chromium.org/2180823004/diff/1/chrome/browser/resources/se...
chrome/browser/resources/settings/clear_browsing_data_dialog/clear_browsing_data_dialog.html:110:
<dialog is="cr-dialog" id="dialog"
with-backdrop="[[!showHistoryDeletionDialog_]]">
On 2016/07/26 at 23:36:12, Dan Beam wrote:
> nit: 80 col wrap

Ah, I am realizing that |with-backdrop| is something that the new version of
<cr-dialog> does not take into account. Will need to come up with something to
accommodate that case.

https://codereview.chromium.org/2180823004/diff/1/ui/webui/resources/cr_eleme...
File ui/webui/resources/cr_elements/cr_dialog/cr_dialog.html (right):

https://codereview.chromium.org/2180823004/diff/1/ui/webui/resources/cr_eleme...
ui/webui/resources/cr_elements/cr_dialog/cr_dialog.html:90: }
On 2016/07/26 at 23:36:12, Dan Beam wrote:
> i would argue that these should go on the top of the list of rules in this
<style> tag

Done.

https://codereview.chromium.org/2180823004/diff/20001/ui/webui/resources/cr_e...
File ui/webui/resources/cr_elements/cr_dialog/cr_dialog.js (right):

https://codereview.chromium.org/2180823004/diff/20001/ui/webui/resources/cr_e...
ui/webui/resources/cr_elements/cr_dialog/cr_dialog.js:9: * Additionally clients
can inspect the dialog's |returnValue| property inisde
On 2016/07/26 at 23:36:12, Dan Beam wrote:
> inisde -> inside

Done.

https://codereview.chromium.org/2180823004/diff/20001/ui/webui/resources/cr_e...
ui/webui/resources/cr_elements/cr_dialog/cr_dialog.js:11: * where a truthy value
means it was not canceled, and a falsy value means it
On 2016/07/26 at 23:36:12, Dan Beam wrote:
> where a truthy value means success, and a falsy value means it was canceled.

Done.

[dpapad, 2016-07-27 01:54:16]

Regarding the CBD double dialog issue, here is the visual difference of before
and after http://imgur.com/a/kWxK0, where the native implementation of cr-dialog
ends up applying the backdrop twice. Not a huge deal IMO, but I think we can
easily address it mimic previous behavior.

[michaelpg, 2016-07-28 16:50:51]

Not familiar with any of the dialog stuff, so don't consider me a reviewer, but
here's what I would think when I try to use this CL to add a dialog.

https://codereview.chromium.org/2180823004/diff/40001/ui/webui/resources/cr_e...
File ui/webui/resources/cr_elements/cr_dialog/cr_dialog.js (right):

https://codereview.chromium.org/2180823004/diff/40001/ui/webui/resources/cr_e...
ui/webui/resources/cr_elements/cr_dialog/cr_dialog.js:10: * the 'close' callback
to determine whether it was canceled or just closed,
"callback" is confusing here, since close is also the name of the method on this
element and the method it overrides. i think "the 'close' event listener" is
better

it's also confusing that |returnValue| is an unrelated property of the event
passed to the 'close' listener :-\

https://codereview.chromium.org/2180823004/diff/40001/ui/webui/resources/cr_e...
ui/webui/resources/cr_elements/cr_dialog/cr_dialog.js:19:
HTMLDialogElement.prototype.close.call(this);
shouldn't this provide the returnValue argument ''? otherwise the
this.returnValue property may still be 'success' after a previous call to
this.close()

https://codereview.chromium.org/2180823004/diff/40001/ui/webui/resources/cr_e...
ui/webui/resources/cr_elements/cr_dialog/cr_dialog.js:26: close:
function(opt_returnValue) {
it looks like nobody ever uses this parameter -- why is it here?

https://codereview.chromium.org/2180823004/diff/40001/ui/webui/resources/cr_e...
ui/webui/resources/cr_elements/cr_dialog/cr_dialog.js:27:
HTMLDialogElement.prototype.close.call(this, 'success');
why include opt_returnValue only to discard it?

[Dan Beam, 2016-07-28 17:31:44]

https://codereview.chromium.org/2180823004/diff/40001/ui/webui/resources/cr_e...
File ui/webui/resources/cr_elements/cr_dialog/cr_dialog.js (right):

https://codereview.chromium.org/2180823004/diff/40001/ui/webui/resources/cr_e...
ui/webui/resources/cr_elements/cr_dialog/cr_dialog.js:10: * the 'close' callback
to determine whether it was canceled or just closed,
On 2016/07/28 16:50:50, michaelpg wrote:
> "callback" is confusing here, since close is also the name of the method on
this
> element and the method it overrides. i think "the 'close' event listener" is
> better

that's fine by me

> 
> it's also confusing that |returnValue| is an unrelated property of the event
> passed to the 'close' listener :-\

there's a HTMLDialogElement#returnValue -- is that the one you're thinking
about?
https://html.spec.whatwg.org/multipage/forms.html#dom-dialog-returnvalue

https://codereview.chromium.org/2180823004/diff/40001/ui/webui/resources/cr_e...
ui/webui/resources/cr_elements/cr_dialog/cr_dialog.js:19:
HTMLDialogElement.prototype.close.call(this);
On 2016/07/28 16:50:50, michaelpg wrote:
> shouldn't this provide the returnValue argument ''? otherwise the
> this.returnValue property may still be 'success' after a previous call to
> this.close()

undefined results in '' as a returnValue (of the dialog, not the event) each
time the dialog is closed

we didn't design this API, it's native HTMLDialogElement

https://codereview.chromium.org/2180823004/diff/40001/ui/webui/resources/cr_e...
ui/webui/resources/cr_elements/cr_dialog/cr_dialog.js:26: close:
function(opt_returnValue) {
On 2016/07/28 16:50:50, michaelpg wrote:
> it looks like nobody ever uses this parameter -- why is it here?

we're overriding native HTMLDialogElement#close

https://codereview.chromium.org/2180823004/diff/40001/ui/webui/resources/cr_e...
ui/webui/resources/cr_elements/cr_dialog/cr_dialog.js:27:
HTMLDialogElement.prototype.close.call(this, 'success');
On 2016/07/28 16:50:50, michaelpg wrote:
> why include opt_returnValue only to discard it?

see above

[Dan Beam, 2016-07-28 17:33:16]

On 2016/07/27 01:54:16, dpapad wrote:
> Regarding the CBD double dialog issue, here is the visual difference of before
> and after http://imgur.com/a/kWxK0, where the native implementation of
cr-dialog
> ends up applying the backdrop twice. Not a huge deal IMO, but I think we can
> easily address it mimic previous behavior.

if we didn't apply the backdrop another time, the user would be able to interact
with CBD while the other dialog was above it, right?  we don't really want that.
 and just making the backdrop clear or something would probably be equaling
confusing.  i'm fine with this.  it's possible others wont be

[dpapad, 2016-07-28 18:47:24]

On 2016/07/28 at 17:33:16, dbeam wrote:
> On 2016/07/27 01:54:16, dpapad wrote:
> > Regarding the CBD double dialog issue, here is the visual difference of
before
> > and after http://imgur.com/a/kWxK0, where the native implementation of
cr-dialog
> > ends up applying the backdrop twice. Not a huge deal IMO, but I think we can
> > easily address it mimic previous behavior.
> 
> if we didn't apply the backdrop another time, the user would be able to
interact with CBD while the other dialog was above it, right?  we don't really
want that.  and just making the backdrop clear or something would probably be
equaling confusing.  i'm fine with this.  it's possible others wont be

Removed the "with-backdrop" property for now, I am fine with double backdrop
too. We can adjust later if others are not OK with it (although I think it is a
minute detail since this is the only case of a double dialog AFAIK).

Whether a dialog is modal, is not determined by whether it has a visible
backdrop or not. It is the show() vs showModal() call that determines that. We
could simply make the backdrop transparent and still have the desired behavior
(not being able to interact with any dialog that is not on top), if we have to.

[dpapad, 2016-07-28 18:47:34]

https://codereview.chromium.org/2180823004/diff/40001/ui/webui/resources/cr_e...
File ui/webui/resources/cr_elements/cr_dialog/cr_dialog.js (right):

https://codereview.chromium.org/2180823004/diff/40001/ui/webui/resources/cr_e...
ui/webui/resources/cr_elements/cr_dialog/cr_dialog.js:19:
HTMLDialogElement.prototype.close.call(this);
On 2016/07/28 at 17:31:43, Dan Beam wrote:
> On 2016/07/28 16:50:50, michaelpg wrote:
> > shouldn't this provide the returnValue argument ''? otherwise the
> > this.returnValue property may still be 'success' after a previous call to
> > this.close()
> 
> undefined results in '' as a returnValue (of the dialog, not the event) each
time the dialog is closed
> 
> we didn't design this API, it's native HTMLDialogElement

Actually after trying this manually it turns out that calling
HTMLDialogElement#close() will not override previous value if it is called with
no arguments, so I changed this to always pass the empty string.

[Dan Beam, 2016-07-28 19:06:23]

On 2016/07/28 18:47:34, dpapad wrote:
>
https://codereview.chromium.org/2180823004/diff/40001/ui/webui/resources/cr_e...
> File ui/webui/resources/cr_elements/cr_dialog/cr_dialog.js (right):
> 
>
https://codereview.chromium.org/2180823004/diff/40001/ui/webui/resources/cr_e...
> ui/webui/resources/cr_elements/cr_dialog/cr_dialog.js:19:
> HTMLDialogElement.prototype.close.call(this);
> On 2016/07/28 at 17:31:43, Dan Beam wrote:
> > On 2016/07/28 16:50:50, michaelpg wrote:
> > > shouldn't this provide the returnValue argument ''? otherwise the
> > > this.returnValue property may still be 'success' after a previous call to
> > > this.close()
> > 
> > undefined results in '' as a returnValue (of the dialog, not the event) each
> time the dialog is closed
> > 
> > we didn't design this API, it's native HTMLDialogElement
> 
> Actually after trying this manually it turns out that calling
> HTMLDialogElement#close() will not override previous value if it is called
with
> no arguments, so I changed this to always pass the empty string.

yeah, the spec wording on this is subtle (it's not clear whether passing
undefined should be interpreted as '').  Thanks for trying it.

[Dan Beam, 2016-07-28 19:09:35]

lgtm

https://codereview.chromium.org/2180823004/diff/40001/chrome/test/data/webui/...
File chrome/test/data/webui/settings/certificate_manager_page_test.js (right):

https://codereview.chromium.org/2180823004/diff/40001/chrome/test/data/webui/...
chrome/test/data/webui/settings/certificate_manager_page_test.js:732: var
observer = new MutationObserver(function(mutations) {
mind == blown

[dpapad, 2016-07-28 19:29:31]

Thank you.

https://codereview.chromium.org/2180823004/diff/40001/chrome/test/data/webui/...
File chrome/test/data/webui/settings/certificate_manager_page_test.js (right):

https://codereview.chromium.org/2180823004/diff/40001/chrome/test/data/webui/...
chrome/test/data/webui/settings/certificate_manager_page_test.js:732: var
observer = new MutationObserver(function(mutations) {
On 2016/07/28 at 19:09:35, Dan Beam wrote:
> mind == blown

Ack!

[dpapad, 2016-07-28 19:34:43]

The CQ bit was checked by dpapad@chromium.org

[commit-bot: I haz the power, 2016-07-28 19:35:22]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-28 20:42:17]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-28 20:42:22]

Failed to apply patch for
chrome/browser/resources/settings/privacy_page/privacy_page.js:
While running git apply --index -3 -p1;
  error: patch failed:
chrome/browser/resources/settings/privacy_page/privacy_page.js:96
  Falling back to three-way merge...
  Applied patch to
'chrome/browser/resources/settings/privacy_page/privacy_page.js' with conflicts.
  U chrome/browser/resources/settings/privacy_page/privacy_page.js

Patch:       chrome/browser/resources/settings/privacy_page/privacy_page.js
Index: chrome/browser/resources/settings/privacy_page/privacy_page.js
diff --git a/chrome/browser/resources/settings/privacy_page/privacy_page.js
b/chrome/browser/resources/settings/privacy_page/privacy_page.js
index
f774ec9a32106b31e7f282726f6bb0aad026b052..b1aaf1805e94f727a769ed01fd0a54f3b7e92ac0
100644
--- a/chrome/browser/resources/settings/privacy_page/privacy_page.js
+++ b/chrome/browser/resources/settings/privacy_page/privacy_page.js
@@ -44,17 +44,6 @@ Polymer({
     this.ContentSettingsTypes = settings.ContentSettingsTypes;
   },
 
-  /** @suppress {missingProperties} */
-  attached: function() {
-    settings.main.rendered.then(function() {
-      if (this.showClearBrowsingDataDialog_) {
-        var dialog = this.$$('settings-clear-browsing-data-dialog').$.dialog;
-        // TODO(dbeam): cast to a CrDialogElement when it compiles.
-        dialog.refit();
-      }
-    }.bind(this));
-  },
-
   /**
    * @return {boolean} Whether the Clear Browsing Data dialog should be
showing.
    * @private
@@ -96,10 +85,7 @@ Polymer({
    * @param {!Event} event
    * @private
    */
-  onIronOverlayClosed_: function(event) {
-    if (Polymer.dom(event).rootTarget.tagName != 'CR-DIALOG')
-      return;
-
+  onDialogClosed_: function(event) {
     this.currentRoute = {
       page: 'advanced',
       section: 'privacy',

[dpapad, 2016-07-28 20:54:03]

The CQ bit was checked by dpapad@chromium.org

[dpapad, 2016-07-28 20:54:04]

The patchset sent to the CQ was uploaded after l-g-t-m from dbeam@chromium.org
Link to the patchset: https://codereview.chromium.org/2180823004/#ps80001
(title: "Merge conflicts with Tommy's CL.")

[commit-bot: I haz the power, 2016-07-28 20:54:23]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[dpapad, 2016-07-28 21:19:19]

The CQ bit was unchecked by dpapad@chromium.org

[dpapad, 2016-07-28 21:32:27]

The CQ bit was checked by dpapad@chromium.org

[commit-bot: I haz the power, 2016-07-28 21:32:52]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-28 21:54:49]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2016-07-28 21:56:37]

Description was changed from

==========
Migrate <cr-dialog> from PaperDialogBehavior to native <dialog>.

 - Make <cr-dialog> extend a native <dialog> element.
 - Modify <cr-dialog> API as follows
   Events renamed:
     'iron-overlay-closed' -> 'close'
     'iron-overlay-canceled' -> 'cancel'
     'iron-overlay-opened' -> No equivalent event. Can be added if it
     turns out to be necessary.
   Method rename: 'open()' -> 'showModal()'
   Attribute rename: 'opened' -> 'open'

Also since HTMLDialogElement#showModal() and HTMLDialogElement#close()
are stricter than equivalent PaperDialogBehavior methods, the following
<cr-dialog> behavioral changes are caused by this migration.

 1) Calling showModal() when the element is not in the DOM throws exception.
 2) Calling showModal()/close() when dialog is already opened/closed throws
    exception.

BUG=625332
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation
==========

to

==========
Migrate <cr-dialog> from PaperDialogBehavior to native <dialog>.

 - Make <cr-dialog> extend a native <dialog> element.
 - Modify <cr-dialog> API as follows
   Events renamed:
     'iron-overlay-closed' -> 'close'
     'iron-overlay-canceled' -> 'cancel'
     'iron-overlay-opened' -> No equivalent event. Can be added if it
     turns out to be necessary.
   Method rename: 'open()' -> 'showModal()'
   Attribute rename: 'opened' -> 'open'

Also since HTMLDialogElement#showModal() and HTMLDialogElement#close()
are stricter than equivalent PaperDialogBehavior methods, the following
<cr-dialog> behavioral changes are caused by this migration.

 1) Calling showModal() when the element is not in the DOM throws exception.
 2) Calling showModal()/close() when dialog is already opened/closed throws
    exception.

BUG=625332
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Committed: https://crrev.com/0501e1b4e707a2d7f4a0525f2f9b0b1ba2dac644
Cr-Commit-Position: refs/heads/master@{#408495}
==========

[commit-bot: I haz the power, 2016-07-28 21:56:39]

Patchset 5 (id:??) landed as
https://crrev.com/0501e1b4e707a2d7f4a0525f2f9b0b1ba2dac644
Cr-Commit-Position: refs/heads/master@{#408495}