Block printing from blocked popup.

chrome/renderer/print_web_view_helper.cc

Index: chrome/renderer/print_web_view_helper.cc
diff --git a/chrome/renderer/print_web_view_helper.cc b/chrome/renderer/print_web_view_helper.cc
index 5352be313bf617cb8c791af05d0d9de614a5b17c..505a4d0b1445d858d6c6c3d4104294c7df0f3a42 100644
--- a/chrome/renderer/print_web_view_helper.cc
+++ b/chrome/renderer/print_web_view_helper.cc
@@ -661,6 +661,18 @@ PrintWebViewHelper::PrintWebViewHelper(content::RenderView* render_view)
 
 PrintWebViewHelper::~PrintWebViewHelper() {}
 
+bool PrintWebViewHelper::IsScriptInitiatedPrintAllowed(
+    WebKit::WebFrame* frame) {
+  if (IsScriptInitiatedPrintTooFrequent(frame))
+    return false;
+  bool allowed = false;
+  IPC::SyncMessage* msg =
+      new PrintHostMsg_CheckScriptedPrintAllowed(routing_id(), &allowed);
+  msg->EnableMessagePumping();

[Lei Zhang, 2012/03/19 20:19:32]

This is not necessary. Just send the message.

[Albert Bodenhamer, 2012/03/19 23:16:17]

Actually it is.  Attempting to Send a sync message here without first calling
EnableMessagePumping results in a DCHECK firing that warns of potential
deadlock.

[Lei Zhang, 2012/03/20 20:34:02]

Oh right, that goes to the UI thread and you'd get the warning on Windows. Umm,
we should avoid using nested message loops as much as possible. If you want a
lecture on why people hate them, talk to jar@.

I slept on this and came up with an alternate way of doing this, without nested
message loops. WDYT?
https://chromiumcodereview.appspot.com/9762004

+  Send(msg);
+  return allowed;
+}
+
 // Prints |frame| which called window.print().
 void PrintWebViewHelper::PrintPage(WebKit::WebFrame* frame) {
   DCHECK(frame);
@@ -671,7 +683,7 @@ void PrintWebViewHelper::PrintPage(WebKit::WebFrame* frame) {
     return;
   }
 
-  if (IsScriptInitiatedPrintTooFrequent(frame))
+  if (!IsScriptInitiatedPrintAllowed(frame))
     return;
   IncrementScriptedPrintCount();