[CUPS] Fix the issue the default queue value not being persisted with each new printer setup.

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

Index: chrome/browser/resources/settings/printing_page/cups_add_printer_dialog.js
diff --git a/chrome/browser/resources/settings/printing_page/cups_add_printer_dialog.js b/chrome/browser/resources/settings/printing_page/cups_add_printer_dialog.js
index d97e93bd526bea01795afe316b1875f942fcf82c..f1a38cdb89cb3e466e287df0e9fe5273066f1aeb 100644
--- a/chrome/browser/resources/settings/printing_page/cups_add_printer_dialog.js
+++ b/chrome/browser/resources/settings/printing_page/cups_add_printer_dialog.js
@@ -135,7 +135,7 @@ Polymer({
           printerName: '',
           printerPPDPath: '',
           printerProtocol: 'ipp',
-          printerQueue: 'ipp/print',
+          printerQueue: '',
           printerStatus: '',
         };
       },
@@ -155,6 +155,10 @@ Polymer({
 
   /** @private */
   switchToManufacturerDialog_: function() {
+    // Set the default printer queue to be "ipp/print".
+    if (!this.newPrinter.printerQueue)
+      this.newPrinter.printerQueue = "ipp/print";

[michaelpg, 2017/05/04 22:30:10]

here and elsewhere, why does this work? Normally Polymer would need to be
notified of the change for data binding to update. Since this is setting a
subproperty directly instead of with this.set(), I'd expect the UI to not get
updated with the new value.

Maybe it's okay here because we're closing the dialog, but what about in
onProtocolChange_ below?

[xdai1, 2017/05/05 00:45:37]

I think the root reason is it means I don't fully understand how Polymer data
binding works... But for this specific case, I think the reason it works here
and in onProtocolChange_() is there is no need of UI update for printerQueue and
printerProtocol.

I modified all the places that modify a subproperty to this.set(...).

[michaelpg, 2017/05/05 19:10:46]

It's black magic, none of us do :-)

But generally, Polymer automatically notices and propagates a change *only* if
the property being set is a top-level Polymer property, *or* if you call
this.set/this.notifyPath.
https://www.polymer-project.org/1.0/docs/devguide/model-data#set-path

Polymer properties, like this.newPrinter, are setters/getters. When you "set"
this.newPrinter = foo, you actually call a Polymer method, which takes care of
updating the backing "newPrinter" value *and* notifies observers and bindings
that the value of this.newPrinter is changed.

When you update a sub-property, like this.newPrinter.bar = foo, Polymer doesn't
know. this.newPrinter is just a getter, so it returns the real "newPrinter"
object. Setting a property of that object doesn't trigger any magic because it's
just a plain old JavaScript object.

[michaelpg, 2017/05/05 20:45:49]

Replying to your message:
Basically, yes. Unless you can guarantee that it won't affect the UI, like if
you're always setting this.newPrinter to a completely new object.

You can still update a sub-property with normal data binding too:
  <paper-input value="{{newPrinter.foo}}">

+
     this.$$('add-printer-dialog').close();
     this.fire('open-manufacturer-model-dialog');
   },