Check for RPCS printers and return error if Win8+

chrome/browser/resources/print_preview/previewarea/preview_area.js

Index: chrome/browser/resources/print_preview/previewarea/preview_area.js
diff --git a/chrome/browser/resources/print_preview/previewarea/preview_area.js b/chrome/browser/resources/print_preview/previewarea/preview_area.js
index ca553a7c7a1102a1c5cf4aee36ab9b713ccaa22f..2954711ca86410c426d2f97fc872d7aca9d99125 100644
--- a/chrome/browser/resources/print_preview/previewarea/preview_area.js
+++ b/chrome/browser/resources/print_preview/previewarea/preview_area.js
@@ -306,6 +306,14 @@ cr.define('print_preview', function() {
      */
     showCustomMessage: function(message) {
       this.showMessage_(PreviewArea.MessageId_.CUSTOM, message);
+      if (this.loadingTimeout_) {

[dpapad, 2017/03/08 23:37:01]

The same logic to clear the timeout is repeated in other places in this file,
see onPreviewGenerationFailed and onPluginLoaded. Can we create a
cancelTimeout() helper method instead and use it in all places?

Having said that, I am still trying to understand the case where we need to
cancel the timeout here. I don't fully understand why it is now the
responsibility of showCustomMessage() to do anything about the timeout. Is there
a more appropriate place we could move this, outside showCustomMessage?

[rbpotter, 2017/03/09 00:42:48]

Refactored.

I moved this into print_preview in onSettingsInvalid_, the function
that calls this. Let me know if this seems like a more reasonable
place for it.

+        // If this is true another event that triggered a "Preview Loading..."
+        // message arrived just before this one and the timeout will cause
+        // this message to be overwritten when it expires. Clear the timeout
+        // so this doesn't occur.
+        clearTimeout(this.loadingTimeout_);
+        this.loadingTimeout_ = null;
+      }
     },
 
     /** @override */