MD User Manager: Refactors existing dialogs in User Manager into <user-manager-dialog>

MD User Manager: Refactors existing dialogs in User Manager into <user-manager-dialog>

BUG=563722
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation

Committed: https://crrev.com/4a0f8751743ee2cc5eb24573963866344470d7b2
Cr-Commit-Position: refs/heads/master@{#398969}

[Moe, 2016-06-01 14:53:16]

Description was changed from

==========
MD User Manager: Refactors existing dialogs in User Manager into
<user-manager-dialog>

BUG=563722
==========

to

==========
MD User Manager: Refactors existing dialogs in User Manager into
<user-manager-dialog>

BUG=563722
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation
==========

[Moe, 2016-06-01 15:27:04]

Patchset #1 (id:1) has been deleted

[Moe, 2016-06-01 15:33:47]

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

[Moe, 2016-06-01 15:33:48]

Hi Demetrios, Please review this CL.

PS. I tried re-using Polymer.PaperDialogBehavior in user-manager-dialog but gave
up b/c it has a weird behavior wrt capturing keyboard events and caching
focusable children. For example, if you have a button that is disabled on
dialog.open() and later you re-enable it won't receive keyboard focus. I might
open a bug or offer a solution for that. But for now, my own implementation gets
the job done.

Thank you.

[Moe, 2016-06-01 15:35:27]

mahmadi@chromium.org changed reviewers:
+ rogerta@chromium.org

[Moe, 2016-06-01 15:35:27]

+rogerta@, Please take a look at:
c/b/ui/webui/signin/md_user_manager_ui.cc

[dpapad, 2016-06-01 19:05:42]

On 2016/06/01 at 15:33:48, mahmadi wrote:
> Hi Demetrios, Please review this CL.
> 
> PS. I tried re-using Polymer.PaperDialogBehavior in user-manager-dialog but
gave up b/c it has a weird behavior wrt capturing keyboard events and caching
focusable children. For example, if you have a button that is disabled on
dialog.open() and later you re-enable it won't receive keyboard focus. I might
open a bug or offer a solution for that. But for now, my own implementation gets
the job done.
> 
> Thank you.

+dbeam
Does your dialog respond to resizing of the browser window, or when the contents
of the dialog dynamically change in size? How does it handle overflow? Asking
because getting a dialog right is pretty complex and a lot of that work has been
done for <settings-dialog> already. Perhaps with a little bit of work we can
re-share <settings-dialog> outside of settings. I understand that there are bugs
in PaperDialogBehavior, but I think they can't they be addressed in your own
instance of the behavior until they are fixed upstream?

[Roger Tawa OOO till Jul 10th, 2016-06-01 20:43:35]

c/b/ui/webui/signin/md_user_manager_ui.cc lgtm

[dpapad, 2016-06-01 20:47:04]

On 2016/06/01 at 19:05:42, dpapad wrote:
> On 2016/06/01 at 15:33:48, mahmadi wrote:
> > Hi Demetrios, Please review this CL.
> > 
> > PS. I tried re-using Polymer.PaperDialogBehavior in user-manager-dialog but
gave up b/c it has a weird behavior wrt capturing keyboard events and caching
focusable children. For example, if you have a button that is disabled on
dialog.open() and later you re-enable it won't receive keyboard focus. I might
open a bug or offer a solution for that. But for now, my own implementation gets
the job done.
> > 
> > Thank you.
> 
> +dbeam
> Does your dialog respond to resizing of the browser window, or when the
contents of the dialog dynamically change in size? How does it handle overflow?
Asking because getting a dialog right is pretty complex and a lot of that work
has been done for <settings-dialog> already. Perhaps with a little bit of work
we can re-share <settings-dialog> outside of settings. I understand that there
are bugs in PaperDialogBehavior, but I think they can't they be addressed in
your own instance of the behavior until they are fixed upstream?

BTW, forgot to link to the spec for the settings-dialog, see
https://folio.googleplex.com/chrome-ux-specs-and-sources/Chrome%20Inner%20Pag....

[Dan Beam, 2016-06-02 00:49:05]

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

[Dan Beam, 2016-06-02 00:49:06]

where are the mocks for this dialog?

https://codereview.chromium.org/2024233003/diff/20001/chrome/browser/resource...
File chrome/browser/resources/md_user_manager/user_manager_dialog.js (right):

https://codereview.chromium.org/2024233003/diff/20001/chrome/browser/resource...
chrome/browser/resources/md_user_manager/user_manager_dialog.js:29:
this.$$('paper-icon-button').focus();
does pressing "Eneter" immediately when shown perform a desired, default action
with this focus() call?

[Moe, 2016-06-03 21:51:39]

On 2016/06/02 00:49:06, Dan Beam wrote:
> where are the mocks for this dialog?
> 
>
https://codereview.chromium.org/2024233003/diff/20001/chrome/browser/resource...
> File chrome/browser/resources/md_user_manager/user_manager_dialog.js (right):
> 
>
https://codereview.chromium.org/2024233003/diff/20001/chrome/browser/resource...
> chrome/browser/resources/md_user_manager/user_manager_dialog.js:29:
> this.$$('paper-icon-button').focus();
> does pressing "Eneter" immediately when shown perform a desired, default
action
> with this focus() call?

My custom dialog does respond to resizing of the browser window and changes in
the sizes of dialog's contents. I do of course prefer to re-use
Polymer.PaperDialogBehavior. It has a lot of nice benefits including handling
ESC key, keeping the focus inside the dialog, accessibility, etc etc. But as you
can see in patch #3 vs patch #2 re-using it might require some hackiness. If you
guys think this solution is acceptable, i'd be glad to help refactor these
changes into a common cr_dialog or something like that.

Mockups are here:
https://folio.googleplex.com/chrome-ux-specs-and-sources/Chrome%20Desktop%20S...
https://folio.googleplex.com/chrome-ux-specs-and-sources/Chrome%20Desktop%20S...

[Moe, 2016-06-03 21:51:50]

https://codereview.chromium.org/2024233003/diff/20001/chrome/browser/resource...
File chrome/browser/resources/md_user_manager/user_manager_dialog.js (right):

https://codereview.chromium.org/2024233003/diff/20001/chrome/browser/resource...
chrome/browser/resources/md_user_manager/user_manager_dialog.js:29:
this.$$('paper-icon-button').focus();
On 2016/06/02 00:49:06, Dan Beam wrote:
> does pressing "Eneter" immediately when shown perform a desired, default
action
> with this focus() call?

For the error-dialog, yes. For the import-supervised-user dialog no. If we
decide to go with this custom dialog, this can be changed to
Polymer.dom(this).querySelector('[defaultfocus]') similar to
Polymer.IronOverlayBehavior

https://codereview.chromium.org/2024233003/diff/40001/chrome/browser/resource...
File chrome/browser/resources/md_user_manager/compiled_resources2.gyp (right):

https://codereview.chromium.org/2024233003/diff/40001/chrome/browser/resource...
chrome/browser/resources/md_user_manager/compiled_resources2.gyp:66:
'target_name': 'user_manager_dialog',
Had to remove this target b/c adding the following to the dependencies was
breaking the closure compiler.

'<(DEPTH)/third_party/polymer/v1_0/components-chromium/paper-dialog-behavior/compiled_resources2.gyp:paper-dialog-behavior-extracted',

https://codereview.chromium.org/2024233003/diff/60001/chrome/browser/resource...
File chrome/browser/resources/md_user_manager/user_manager_dialog.js (right):

https://codereview.chromium.org/2024233003/diff/60001/chrome/browser/resource...
chrome/browser/resources/md_user_manager/user_manager_dialog.js:62:
this.__firstFocusableNode = newValue;
__firstFocusableNode is not part of PaperDialogBehavior's paper dialog. But this
is the only way I could come up with to update the focusable nodes *after* the
dialog opens. Same thing below.

[Dan Beam, 2016-06-03 22:00:47]

https://codereview.chromium.org/2024233003/diff/40001/chrome/browser/resource...
File chrome/browser/resources/md_user_manager/compiled_resources2.gyp (right):

https://codereview.chromium.org/2024233003/diff/40001/chrome/browser/resource...
chrome/browser/resources/md_user_manager/compiled_resources2.gyp:66:
'target_name': 'user_manager_dialog',
On 2016/06/03 21:51:50, Moe wrote:
> Had to remove this target b/c adding the following to the dependencies was
> breaking the closure compiler.
> 
>
'<(DEPTH)/third_party/polymer/v1_0/components-chromium/paper-dialog-behavior/compiled_resources2.gyp:paper-dialog-behavior-extracted',

why?  can you paste the error?

it's better to fix the polymer compilation errors than just ... not compile our
code

[Moe, 2016-06-06 16:29:20]

https://codereview.chromium.org/2024233003/diff/40001/chrome/browser/resource...
File chrome/browser/resources/md_user_manager/compiled_resources2.gyp (right):

https://codereview.chromium.org/2024233003/diff/40001/chrome/browser/resource...
chrome/browser/resources/md_user_manager/compiled_resources2.gyp:66:
'target_name': 'user_manager_dialog',
On 2016/06/03 22:00:47, Dan Beam wrote:
> On 2016/06/03 21:51:50, Moe wrote:
> > Had to remove this target b/c adding the following to the dependencies was
> > breaking the closure compiler.
> > 
> >
>
'<(DEPTH)/third_party/polymer/v1_0/components-chromium/paper-dialog-behavior/compiled_resources2.gyp:paper-dialog-behavior-extracted',
> 
> why?  can you paste the error?
> 
> it's better to fix the polymer compilation errors than just ... not compile
our
> code

I didn't know we modify the third party Polymer JS code. Should we also always
compile those sources too to prevent such errors?

(ERROR) Error in: iron-overlay-manager-extracted.js
##
/usr/local/google/home/mahmadi/chromium/src/third_party/polymer/v1_0/components-chromium/iron-overlay-behavior/iron-overlay-manager-extracted.js:320:
ERROR - Property _manager never defined on ?
##         if (path[i]._manager === this) {
##                     ^
## 
##
/usr/local/google/home/mahmadi/chromium/src/third_party/polymer/v1_0/components-chromium/iron-overlay-behavior/iron-overlay-manager-extracted.js:377:
ERROR - Property alwaysOnTop never defined on o1
##       return !o1.alwaysOnTop && o2.alwaysOnTop;
##  

you can also run third_party/closure_compiler/run_compiler
paper-dialog-behavior-extracted to reproduce.

[dpapad, 2016-06-06 17:53:54]

On 2016/06/06 at 16:29:20, mahmadi wrote:
>
https://codereview.chromium.org/2024233003/diff/40001/chrome/browser/resource...
> File chrome/browser/resources/md_user_manager/compiled_resources2.gyp (right):
> 
>
https://codereview.chromium.org/2024233003/diff/40001/chrome/browser/resource...
> chrome/browser/resources/md_user_manager/compiled_resources2.gyp:66:
'target_name': 'user_manager_dialog',
> On 2016/06/03 22:00:47, Dan Beam wrote:
> > On 2016/06/03 21:51:50, Moe wrote:
> > > Had to remove this target b/c adding the following to the dependencies was
> > > breaking the closure compiler.
> > > 
> > >
> >
'<(DEPTH)/third_party/polymer/v1_0/components-chromium/paper-dialog-behavior/compiled_resources2.gyp:paper-dialog-behavior-extracted',
> > 
> > why?  can you paste the error?
> > 
> > it's better to fix the polymer compilation errors than just ... not compile
our
> > code
> 
> I didn't know we modify the third party Polymer JS code. Should we also always
compile those sources too to prevent such errors?
> 
> (ERROR) Error in: iron-overlay-manager-extracted.js
> ##
/usr/local/google/home/mahmadi/chromium/src/third_party/polymer/v1_0/components-chromium/iron-overlay-behavior/iron-overlay-manager-extracted.js:320:
ERROR - Property _manager never defined on ?
> ##         if (path[i]._manager === this) {
> ##                     ^
> ## 
> ##
/usr/local/google/home/mahmadi/chromium/src/third_party/polymer/v1_0/components-chromium/iron-overlay-behavior/iron-overlay-manager-extracted.js:377:
ERROR - Property alwaysOnTop never defined on o1
> ##       return !o1.alwaysOnTop && o2.alwaysOnTop;
> ##  
> 
> you can also run third_party/closure_compiler/run_compiler
paper-dialog-behavior-extracted to reproduce.

FWIW, I've encountered compile errors too when trying to compile files that
depend on paper-dialolg-behavior-extracted. This is also the reason why we don't
have a settings_dialog GYP target in settings/compiled_resources2.gyp.

[Dan Beam, 2016-06-08 00:26:55]

On 2016/06/06 17:53:54, dpapad wrote:
> On 2016/06/06 at 16:29:20, mahmadi wrote:
> >
>
https://codereview.chromium.org/2024233003/diff/40001/chrome/browser/resource...
> > File chrome/browser/resources/md_user_manager/compiled_resources2.gyp
(right):
> > 
> >
>
https://codereview.chromium.org/2024233003/diff/40001/chrome/browser/resource...
> > chrome/browser/resources/md_user_manager/compiled_resources2.gyp:66:
> 'target_name': 'user_manager_dialog',
> > On 2016/06/03 22:00:47, Dan Beam wrote:
> > > On 2016/06/03 21:51:50, Moe wrote:
> > > > Had to remove this target b/c adding the following to the dependencies
was
> > > > breaking the closure compiler.
> > > > 
> > > >
> > >
>
'<(DEPTH)/third_party/polymer/v1_0/components-chromium/paper-dialog-behavior/compiled_resources2.gyp:paper-dialog-behavior-extracted',
> > > 
> > > why?  can you paste the error?
> > > 
> > > it's better to fix the polymer compilation errors than just ... not
compile
> our
> > > code
> > 
> > I didn't know we modify the third party Polymer JS code. Should we also
always
> compile those sources too to prevent such errors?
> > 
> > (ERROR) Error in: iron-overlay-manager-extracted.js
> > ##
>
/usr/local/google/home/mahmadi/chromium/src/third_party/polymer/v1_0/components-chromium/iron-overlay-behavior/iron-overlay-manager-extracted.js:320:
> ERROR - Property _manager never defined on ?
> > ##         if (path[i]._manager === this) {
> > ##                     ^
> > ## 
> > ##
>
/usr/local/google/home/mahmadi/chromium/src/third_party/polymer/v1_0/components-chromium/iron-overlay-behavior/iron-overlay-manager-extracted.js:377:
> ERROR - Property alwaysOnTop never defined on o1
> > ##       return !o1.alwaysOnTop && o2.alwaysOnTop;
> > ##  
> > 
> > you can also run third_party/closure_compiler/run_compiler
> paper-dialog-behavior-extracted to reproduce.
> 
> FWIW, I've encountered compile errors too when trying to compile files that
> depend on paper-dialolg-behavior-extracted. This is also the reason why we
don't
> have a settings_dialog GYP target in settings/compiled_resources2.gyp.

So the ripple here is that I'm not sure how to describe something to the
compiler that originates from a Behavior[1].  Maybe @lends {BehaviorName} or
just /** @type {ThingThatImplementsBehavior} */() (i.e. IronOverlay)?

[1]
https://cs.chromium.org/chromium/src/third_party/polymer/v1_0/components-chro...

[Dan Beam, 2016-06-08 00:27:12]

Description was changed from

==========
MD User Manager: Refactors existing dialogs in User Manager into
<user-manager-dialog>

BUG=563722
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation
==========

to

==========
MD User Manager: Refactors existing dialogs in User Manager into
<user-manager-dialog>

BUG=563722
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation
==========

[Dan Beam, 2016-06-08 00:27:12]

dbeam@chromium.org changed reviewers:
- dbeam@chromium.org

[Moe, 2016-06-08 20:31:40]

Demetrios, apart from the closure compilation issues, Does this CL look good?

[dpapad, 2016-06-08 23:05:12]

Almost there. Few nit comments and a question about focus related logic in
user_manager_dialog.js

https://codereview.chromium.org/2024233003/diff/100001/chrome/browser/resourc...
File chrome/browser/resources/md_user_manager/error_dialog.html (right):

https://codereview.chromium.org/2024233003/diff/100001/chrome/browser/resourc...
chrome/browser/resources/md_user_manager/error_dialog.html:21: <div
id="message">[[message_]]</div>
Is this 2nd div necessary? Can it be merged to the parent div as follows?

<div id="message" class="body">[[message_]]</div>

https://codereview.chromium.org/2024233003/diff/100001/chrome/browser/resourc...
chrome/browser/resources/md_user_manager/error_dialog.html:25: <script
src="chrome://md-user-manager/error_dialog.js"></script>
Nit: Is this equivalent to the shorter

<script src="error_dialog.js"></script>

Asking because in the future I am guessing that chrome://md-user-manager will be
promoted to simply chrome://user-manager, so not repeating the first part of the
URL if it is not needed seems like a benefit (there will be no need to change
this later).

https://codereview.chromium.org/2024233003/diff/100001/chrome/browser/resourc...
File chrome/browser/resources/md_user_manager/import_supervised_user.js (right):

https://codereview.chromium.org/2024233003/diff/100001/chrome/browser/resourc...
chrome/browser/resources/md_user_manager/import_supervised_user.js:91: *
@private
@param missing

https://codereview.chromium.org/2024233003/diff/100001/chrome/browser/resourc...
chrome/browser/resources/md_user_manager/import_supervised_user.js:92: * @return
{boolean}
The comment mismatches the code, says "true if enabled", but the code returns
true if disabled.


Nit (optional): Remove comment above and merge with the @return

@return {boolean} Whether the 'Import' button should be disabled.

https://codereview.chromium.org/2024233003/diff/100001/chrome/browser/resourc...
File chrome/browser/resources/md_user_manager/user_manager_dialog.js (right):

https://codereview.chromium.org/2024233003/diff/100001/chrome/browser/resourc...
chrome/browser/resources/md_user_manager/user_manager_dialog.js:28: * @type
{Node}
Can this be null? If not, let's change it to !Node.

https://codereview.chromium.org/2024233003/diff/100001/chrome/browser/resourc...
chrome/browser/resources/md_user_manager/user_manager_dialog.js:51: * @type
{Array<Node>}
Should this be !Array<!Node>

https://codereview.chromium.org/2024233003/diff/100001/chrome/browser/resourc...
chrome/browser/resources/md_user_manager/user_manager_dialog.js:62:
this.__firstFocusableNode = newValue;
This method and the next one seem to modify "private" variables of the behavior.
Can you explain a bit why this is needed? Is there a bug on PaperDialogBehavior
that should eventually be fixed upstream?

[Moe, 2016-06-09 14:10:04]

https://codereview.chromium.org/2024233003/diff/100001/chrome/browser/resourc...
File chrome/browser/resources/md_user_manager/error_dialog.html (right):

https://codereview.chromium.org/2024233003/diff/100001/chrome/browser/resourc...
chrome/browser/resources/md_user_manager/error_dialog.html:21: <div
id="message">[[message_]]</div>
On 2016/06/08 23:05:12, dpapad wrote:
> Is this 2nd div necessary? Can it be merged to the parent div as follows?
> 
> <div id="message" class="body">[[message_]]</div>

user-manager-dialog gives a certain padding to body's children. I certainly can
merge the two and apply the padding here. But that'll mean if we ever change the
look and feel of user-manager-dialog we'd have to change this too. I think it's
better to keep the second div.

https://codereview.chromium.org/2024233003/diff/100001/chrome/browser/resourc...
chrome/browser/resources/md_user_manager/error_dialog.html:25: <script
src="chrome://md-user-manager/error_dialog.js"></script>
On 2016/06/08 23:05:12, dpapad wrote:
> Nit: Is this equivalent to the shorter
> 
> <script src="error_dialog.js"></script>
> 
> Asking because in the future I am guessing that chrome://md-user-manager will
be
> promoted to simply chrome://user-manager, so not repeating the first part of
the
> URL if it is not needed seems like a benefit (there will be no need to change
> this later).

Makes sense! I left a todo here to update all these to relative urls in one
future CL.

https://codereview.chromium.org/2024233003/diff/100001/chrome/browser/resourc...
File chrome/browser/resources/md_user_manager/import_supervised_user.js (right):

https://codereview.chromium.org/2024233003/diff/100001/chrome/browser/resourc...
chrome/browser/resources/md_user_manager/import_supervised_user.js:91: *
@private
On 2016/06/08 23:05:12, dpapad wrote:
> @param missing

Done.

https://codereview.chromium.org/2024233003/diff/100001/chrome/browser/resourc...
chrome/browser/resources/md_user_manager/import_supervised_user.js:92: * @return
{boolean}
On 2016/06/08 23:05:12, dpapad wrote:
> The comment mismatches the code, says "true if enabled", but the code returns
> true if disabled.
> 
> 
> Nit (optional): Remove comment above and merge with the @return
> 
> @return {boolean} Whether the 'Import' button should be disabled.

Done. I've seen conflicting reviews about the language "Whether foobar should be
disabled/enabled...". I personally like it though :)

https://codereview.chromium.org/2024233003/diff/100001/chrome/browser/resourc...
File chrome/browser/resources/md_user_manager/user_manager_dialog.js (right):

https://codereview.chromium.org/2024233003/diff/100001/chrome/browser/resourc...
chrome/browser/resources/md_user_manager/user_manager_dialog.js:28: * @type
{Node}
On 2016/06/08 23:05:12, dpapad wrote:
> Can this be null? If not, let's change it to !Node.

Done.

https://codereview.chromium.org/2024233003/diff/100001/chrome/browser/resourc...
chrome/browser/resources/md_user_manager/user_manager_dialog.js:51: * @type
{Array<Node>}
On 2016/06/08 23:05:12, dpapad wrote:
> Should this be !Array<!Node>

Done.

https://codereview.chromium.org/2024233003/diff/100001/chrome/browser/resourc...
chrome/browser/resources/md_user_manager/user_manager_dialog.js:62:
this.__firstFocusableNode = newValue;
On 2016/06/08 23:05:12, dpapad wrote:
> This method and the next one seem to modify "private" variables of the
behavior.
> Can you explain a bit why this is needed? Is there a bug on
PaperDialogBehavior
> that should eventually be fixed upstream?

iron-overlay-behavior wrap the focus for the overlay (keeps the focus inside the
overlay). It provides get _focusableNodes() as a protected function so it can be
overridden to return the first and the last focusable elements if you know what
your content is. However it only looks up _focusableNodes when the dialog opens
and caches the first and the last focusable elements.
This works if the content is static. In import-supervised-user dialog, the
confirm button becomes focusable (enabled) once something is selected on the
dialog. therefore I need to be able to update the "cached" last focusable
element which is not exposed in the API. I'm planning to file a bug and
potentially offer a patch to expose these two variables in the API as I believe
I won't be the first and last person who'd have dynamic focusable content on
their dialogs.

[dpapad, 2016-06-09 17:02:48]

https://codereview.chromium.org/2024233003/diff/100001/chrome/browser/resourc...
File chrome/browser/resources/md_user_manager/import_supervised_user.js (right):

https://codereview.chromium.org/2024233003/diff/100001/chrome/browser/resourc...
chrome/browser/resources/md_user_manager/import_supervised_user.js:92: * @return
{boolean}
> Done. I've seen conflicting reviews about the language "Whether foobar should
be disabled/enabled...". I personally like it though :)

My suggestion comes straight from the style-guide, see
https://google.github.io/styleguide/javascriptguide.xml?showone=Comments#Comm...
(Search for "Whether something occurred")

https://codereview.chromium.org/2024233003/diff/100001/chrome/browser/resourc...
File chrome/browser/resources/md_user_manager/user_manager_dialog.js (right):

https://codereview.chromium.org/2024233003/diff/100001/chrome/browser/resourc...
chrome/browser/resources/md_user_manager/user_manager_dialog.js:62:
this.__firstFocusableNode = newValue;
Thanks for the explanation.

[dpapad, 2016-06-09 17:02:55]

LGTM

[Moe, 2016-06-09 17:16:21]

On 2016/06/09 17:02:55, dpapad wrote:
> LGTM

Thanks Demetrios! I'll remove the gyp target for user_manager_dialog. Please
update me when we do fix paper-dialolg-behavior-extracted.

[Moe, 2016-06-09 17:37:06]

Patchset #8 (id:160001) has been deleted

[Moe, 2016-06-09 17:57:58]

The CQ bit was checked by mahmadi@chromium.org

[Moe, 2016-06-09 17:57:59]

The patchset sent to the CQ was uploaded after l-g-t-m from
rogerta@chromium.org, dpapad@chromium.org
Link to the patchset: https://codereview.chromium.org/2024233003/#ps140001
(title: "Removed user_manager_dialog gyp target")

[commit-bot: I haz the power, 2016-06-09 17:58:26]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2024233003/140001

[commit-bot: I haz the power, 2016-06-09 18:51:14]

Description was changed from

==========
MD User Manager: Refactors existing dialogs in User Manager into
<user-manager-dialog>

BUG=563722
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation
==========

to

==========
MD User Manager: Refactors existing dialogs in User Manager into
<user-manager-dialog>

BUG=563722
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation
==========

[commit-bot: I haz the power, 2016-06-09 18:51:15]

Committed patchset #7 (id:140001)

[commit-bot: I haz the power, 2016-06-09 18:51:26]

CQ bit was unchecked

[commit-bot: I haz the power, 2016-06-09 18:54:14]

Description was changed from

==========
MD User Manager: Refactors existing dialogs in User Manager into
<user-manager-dialog>

BUG=563722
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation
==========

to

==========
MD User Manager: Refactors existing dialogs in User Manager into
<user-manager-dialog>

BUG=563722
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation

Committed: https://crrev.com/4a0f8751743ee2cc5eb24573963866344470d7b2
Cr-Commit-Position: refs/heads/master@{#398969}
==========

[commit-bot: I haz the power, 2016-06-09 18:54:15]

Patchset 7 (id:??) landed as
https://crrev.com/4a0f8751743ee2cc5eb24573963866344470d7b2
Cr-Commit-Position: refs/heads/master@{#398969}