Update CUPS settings UI to allow USB printers to be added via discovery.

chrome/browser/resources/settings/printing_page/cups_add_printer_dialog.html

Index: chrome/browser/resources/settings/printing_page/cups_add_printer_dialog.html
diff --git a/chrome/browser/resources/settings/printing_page/cups_add_printer_dialog.html b/chrome/browser/resources/settings/printing_page/cups_add_printer_dialog.html
index 867ac2c9afabe2f0c7f0263862122e8af716bdc9..35c58e066c73b686ad446783f7f088b85dd50fe0 100644
--- a/chrome/browser/resources/settings/printing_page/cups_add_printer_dialog.html
+++ b/chrome/browser/resources/settings/printing_page/cups_add_printer_dialog.html
@@ -75,7 +75,7 @@
           </paper-button>
           <paper-button class="action-button" id="addPrinterButton"
               disabled="[[!selectedPrinter]]"
-              on-tap="switchToConfiguringDialog_">
+              on-tap="switchToManufacturerDialog_">
             $i18n{addPrinterButtonText}
           </paper-button>
         </div>
@@ -317,8 +317,8 @@
       <div class="dialog-buttons">
         <div>  <!-- Left group -->
           <paper-button id="manuallyAddPrinterButton" class="secondary-button"
-              on-tap="switchToManualAddDialog_">
-            $i18n{manuallyAddPrinterButtonText}
+              on-tap="switchToManualAddDialog_" hidden="[[!inManualFlow]]">

[xdai1, 2017/05/10 20:12:53]

there is no inManualFlow property in add-printer-manufacturer-model-dialog?

[Carlson, 2017/05/10 21:28:17]

This is interesting, because I see what you're saying, yet this does seem to
work.  The back button is hidden if I get there from discovery, and not if I get
there from add manually.

How does scoping work here?  Maybe it's legitimate to reference inManualFlow
from the enclosing settings-cups-add-printer-dialog scope whence this is
instantiated?  If that's true, we probably don't need some of the newPrinter and
selectedPrinter bindings as well.

[xdai1, 2017/05/11 00:25:10]

Not sure exactly why it works here. But I think when "hidden" is binded to
"inManualFlow", Polymer will generate an implicit property "inManualFlow" that
can also be used in "settings-cups-add-printer-dialog" binding. However, I think
we may not be able get rid of newPrinter and selectedPrinter bindings here. It
may be fine if you don't use these implicit properties in the js file. But if
you do need to use the property in the js file, you need to define the property
explicitly. 

[Carlson, 2017/05/11 22:08:58]

Should be better now.

+            $i18n{back}
           </paper-button>
         </div>
         <div>  <!-- Right group -->
@@ -343,7 +343,7 @@
         padding-top: 140px;
         text-align: center;
       }
-    </style>
+      </style>

[xdai1, 2017/05/10 20:12:53]

indent off

[Carlson, 2017/05/10 21:28:17]

Done.

     <add-printer-dialog>
       <div class="dialog-title">[[dialogTitle]]</div>
       <div class="dialog-body">
@@ -366,7 +366,8 @@
 
     <!-- Printer Discovery Dialog -->
     <template is="dom-if" if="[[showDiscoveryDialog_]]" restamp>
-      <add-printer-discovery-dialog selected-printer="{{selectedPrinter}}">
+      <add-printer-discovery-dialog selected-printer="{{selectedPrinter}}"
+                                    new-printer="{{newPrinter}}">

[xdai1, 2017/05/10 20:12:53]

I still feel like add-printer-discovery-dialog should not have a newPrinter
property.

[Carlson, 2017/05/10 21:28:17]

You're right, this isn't needed anymore, I just forgot to remove this.

       </add-printer-discovery-dialog>
     </template>
 
@@ -387,7 +388,8 @@
     <!-- Manufacturer and Model Dialog -->
     <template is="dom-if" if="[[showManufacturerDialog_]]" restamp>
       <add-printer-manufacturer-model-dialog new-printer="{{newPrinter}}"
-          setup-failed="[[setupFailed]]">
+          selected-printer="{{selectedPrinter}}" setup-failed="[[setupFailed]]"
+          in-manual-flow="[[inManualFlow]]">

[xdai1, 2017/05/10 20:12:53]

Does this work? If add-printer-manufacturer-model-dialog doesn't have
inManualFlow, you may not be able use in-manual-flow="[[inManualFlow]].

[Carlson, 2017/05/10 21:28:17]

It does seem to work.  Do you want me to add the property explicitly anyways? 
Not sure if we have redundant code elsewhere, or what I'm doing here is
implicitly bad style.

[xdai1, 2017/05/11 00:25:10]

See my guess in the above comment. If my guess is correct, then we can leave the
code as is since we don't use the property in the js file anyway. Otherwise, it
might be better to add it back explicitly.

[Carlson, 2017/05/11 22:08:58]

I think this is better now.  inManualFlow no longer exists, but we do propagate
previousDialog down, and explicitly declare it as a property in this dialog.

       </add-printer-manufacturer-model-dialog>
     </template>