Current implementation is intentionally following what the old Options banner did (always shown at the top).

Re-assigning to @bettes.

A couple options:
1) If we want to keep this treatment of the banner, it should be covered by a sub-page.
2) If it cannot be covered at all for security/other reasons, alternatively the warning could appear as a toast in the bottom left or a full-page-width banner above/below the app bar.

Re: comment 3, 

If the urgency of this banner is of the most critical, meaning that chrome settings isn't functional, then this banner should be a modal dialog. 

If the urgency is low, meaning that chrome settings is still functional, then this banner should be converted to a toast. 

https://elements.polymer-project.org/elements/paper-toast?view=demo:demo/index.html&active=paper-toast

In either case, we should not be using the banner motif anymore. 

@dbeam: Should this be a dev blocker? Also who is a good person to answer the question about "urgency" of this prompt from previous comment? Converting it to a dialog sounds reasonable to me.

tbuckley@ or bettes@ probably would know how urgent this is

Dialog sounds right to me as well. I wouldn't say it is a dev blocker because:
1) It is very visible today (if not the best looking), so it gets the message across
2) It should (hopefully) be a rare case

Dialog should be using the same template as all others with the buttons:

CANCEL | RESET ALL SETTINGS

@tbuckley: Can you provide the string for the title of the dialog?

Also note that the "RESET ALL SETTINGS" button forwards the user to the reset profile dialog (see screencast). Just mentioning this in case you think that this text needs tweaking too.

Deleted: banner_dialog.mp4 267 KB

	banner_dialog.mp4 267 KB View Download

Dan had concerns about turning this into a modal dialog. This could be annoying to users, compared to the previous UI which could be simply ignored.

So per my understanding, we are faced with the following constraints.
1) Don't block the user on this UI.
2) Need a UI that is visible at all times (even when in a subpage), but without
   breaking how subpages look like, or breaking subpage in/out animations.

My suggestion is to use a infobar at the bottom. Sending this to bettes@ for further consideration.

I want to push more on the modal dialog because it's opinionated, absolute, and doesn't introduce any new outlier patterns. 

None of us seem to have a good idea of how confident and urgent this warning is, so unless Dan can provide some numbers, I think we should continue with the modal dialog. 

I'll assign this to Dan for the time being, and I will work to getting better strings. (Thanks for highlighting the interaction dpapad@)

I volunteer brave dpapad@ to do some git blame archaeology and try to figure out who to ask about confidence.  if we're confident, modal dialog SGTM

Done some research and found the original bug  issue 340803 .

+robertshield: Please see discussion above, along with questions about the urgency of this banner. The debate is whether this UI should be kept as a banner or converted to a modal dialog, for the new Material Design settings. 

From dbeam: just do it (TM)

More info: just make it a dialog.

Apologies, I missed dpapad@'s first query. 

The infobar is there to let the curious user who ventures into their settings know that Chrome had reset something that got tampered with. A dialog accomplishes this as well, though at the time we deemed infobars to be more appropriate for "thing you probably want to know, but don't have to take action on if you don't want to".

One minor edge case is that some users might get this multiple times if malware on their system is constantly tampering with settings. This happen to very few users (malware has mostly adapted) but for those few that it does happen to, visiting settings might be annoying if it were a dialog.

In terms of how confident we are: very - the infobar appeared as a result of Chrome clearing a setting.
In terms of how urgent this is: we deemed it important enough to let the user know what happened if they visit chrome://settings, but not important enough to bother them with if they didn't.

In the end I defer to whichever approach you are most comfortable with and is most maintainable.

Thanks for the explanation.

Thanks for the explanation, Robert. 

If there are no objections, I'd like to move forward with the modal dialog given the high level of confidence and low frequency. This particular situation doesn't warrant new UI paradigms IMO.

dpapad@, feel free to reach out if there's anything else left unresolved. 

@bettes: Please see questions at comment 12 providing missing string for the dialog's title.

FYI: I just addressed a similar issue here:

https://codereview.chromium.org/2687643004/

My solution was to hide the banner when hasExpandedSection_ is true.

(In this case we really do want an infobar, although there is still an open request for an official mock)

It might be worth considering making a similar quick fix and lowering this to a P2?

@stenenjb: I have already implemented this(see comment#12 screencast). Just waiting on bettes/tbuckley to provide missing strings.

@dpapad, when is this dialog shown? Have some/all settings already been reset, or are we suggesting that users reset them? From #18 it sounds like this dialog is only shown when all settings have already been reset by Chrome.

If that's the case, we should change the dialog title "Settings reset" and only have a "Done" button.

If we are in fact prompting users to actually reset settings, let's make the title "Reset settings".

@tbuckley: The dialog is shown when SOME of the settings have been reset. Besides informing the user that this happened, it also offers the user the option to reset ALL SETTINGS. Removing the "ALL" from "Remove all settings" seems confusing to me.

Either way, please refer to the video at comment #12. Clicking on "reset all settings" brings up a 2nd dialog, with the title "Reset". So I think we need to make a distinction between the 1st and 2nd dialogs, and the proposed flow

1st dialog title "Reset settings" -> 2nd dialog "Reset"
does not make it clear which dialog does what.

How about the following?
 - 1st dialog title "Some settings were reset" -> 2nd dialog title "Reset"
 - 1st dialog's buttons [OK] [RESET ALL SETTINGS]

The proposal in #25 works for me.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/da4e99db2db55d566dfbcbf4dfe89fb4c3202ec7

commit da4e99db2db55d566dfbcbf4dfe89fb4c3202ec7
Author: dpapad <dpapad@chromium.org>
Date: Fri Feb 17 00:05:57 2017

MD Settings: Convert reset profile banner to a dialog.

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

Review-Url: https://codereview.chromium.org/2625263002
Cr-Commit-Position: refs/heads/master@{#451145}

[modify] https://crrev.com/da4e99db2db55d566dfbcbf4dfe89fb4c3202ec7/chrome/app/settings_strings.grdp
[modify] https://crrev.com/da4e99db2db55d566dfbcbf4dfe89fb4c3202ec7/chrome/browser/resources/settings/basic_page/basic_page.html
[modify] https://crrev.com/da4e99db2db55d566dfbcbf4dfe89fb4c3202ec7/chrome/browser/resources/settings/basic_page/basic_page.js
[modify] https://crrev.com/da4e99db2db55d566dfbcbf4dfe89fb4c3202ec7/chrome/browser/resources/settings/reset_page/reset_profile_banner.html
[modify] https://crrev.com/da4e99db2db55d566dfbcbf4dfe89fb4c3202ec7/chrome/browser/resources/settings/reset_page/reset_profile_banner.js
[modify] https://crrev.com/da4e99db2db55d566dfbcbf4dfe89fb4c3202ec7/chrome/browser/ui/webui/settings/md_settings_localized_strings_provider.cc
[modify] https://crrev.com/da4e99db2db55d566dfbcbf4dfe89fb4c3202ec7/chrome/test/data/webui/settings/reset_profile_banner_test.js