Chrome: qz:launch shows pop-up

[tresf]

At some point, our code to suppress the qz:launch pop-ups stopped working.

Initial glance would blame the deprecation of URLWhitelist, but changing this to URLAllowlist on Windows doesn't seem to fix the symptom.

• ⚠️ https://chromeenterprise.google/policies/#URLWhitelist
• ✅ https://chromeenterprise.google/policies/#URLAllowlist

Code policy locations -- click to expand (outdated)

Code:

• Mac:
  

  tray/src/qz/installer/MacInstaller.java

  Line 70 in 291200f

  ShellUtilities.execute("/usr/bin/defaults", "write", plist, "URLWhitelist", "-array-add", DATA_DIR +"://*");

• Linux:
  

  tray/src/qz/installer/LinuxInstaller.java

  Line 30 in 291200f

  public static final String CHROME_POLICY = "{ \"URLWhitelist\": [\"" + DATA_DIR + "://*\"] }";

• Windows:
  

  tray/src/qz/installer/WindowsInstaller.java

  Line 148 in 291200f

  WindowsUtilities.addNumberedRegValue(HKEY_LOCAL_MACHINE, "SOFTWARE\\Policies\\Google\\Chrome\\URLWhitelist", String.format("%s://*", DATA_DIR));

With regards to whether or not the "Always allow" checkbox is shown, there's a policy for that as well, which we don't currently configure:

• https://chromeenterprise.google/policies/#ExternalProtocolDialogShowAlwaysOpenCheckbox

Historically, we've suppressed this pop-up via policy, but recent version of Chrome seem to show this pop-up:

[Vzor-]

Changing line 70 to "URLAllowlist" did work for me. Do you see a policy listed under Chrome Policies on chrome://policy/

[tresf]

Changing line 70 to "URLAllowlist" did work for me. Do you see a policy listed under Chrome Policies on chrome://policy/

Great, let's get a PR prepared and then we can retest.

[tresf]

... but changing this to URLAllowlist doesn't seem to fix the symptom.

Changing line 70 to "URLAllowlist" did work for me. Do you see a policy listed under Chrome Policies on chrome://policy/

This statement is not true, at least not for Windows. Quoting #1288 (comment):

This is a working policy on MacOS this is a not working policy on Windows. They seem similar, but there are some minor discrepancies. I'll try resolving these to find the issue.

I've updated the original bug report specify the different behavior on Windows. Let's get this (seemingly upstream) bug documented properly so that we can determine next steps.