ShellUtil: Add generic methods to add/delete Windows file associations.

chrome/browser/file_associations_win.cc

+// Copyright 2014 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#include "chrome/browser/file_associations_win.h"
+
+#include <shlobj.h>
+
+#include "base/strings/utf_string_conversions.h"
+#include "chrome/installer/util/shell_util.h"
+
+bool AddWindowsFileAssociations(const std::string& progid,
+                                const base::CommandLine& command_line,
+                                const std::string& file_type_name,
+                                const base::FilePath& icon_path,
+                                const std::set<std::string>& file_extensions) {
+  std::set<base::string16> file_extensions_16;
+  for (std::set<std::string>::const_iterator it = file_extensions.begin();
+       it != file_extensions.end();
+       ++it) {
+    file_extensions_16.insert(base::UTF8ToUTF16(*it));
+  }
+  if (!ShellUtil::AddFileAssociations(base::UTF8ToUTF16(progid),
+                                      command_line,
+                                      base::UTF8ToUTF16(file_type_name),
+                                      icon_path,
+                                      file_extensions_16)) {
+    return false;
+  }
+
+  // Success. Tell Windows Explorer to update its cache.
+  SHChangeNotify(
+      SHCNE_ASSOCCHANGED, SHCNF_IDLIST | SHCNF_FLUSHNOWAIT, NULL, NULL);

[gab, 2014/09/12 13:32:36]

IIRC this will also produce a fly-in on Win8 telling the user that "a new app
now supports file type X" and asking them to pick their desired default.

Also note that it will clear the icon cache (forcing a taskbar/desktop flash of
all icons) -- to be used with caution.

I also don't think you want to use SHCNF_FLUSHNOWAIT (it has caused problems in
the past: http://crbug.com/136567 and shouldn't be used only you can explicitly
justify why you want it).

[gab, 2014/09/18 01:16:14]

ping.

[Matt Giuca, 2014/09/30 10:21:12]

I tried this on Windows 8 and I didn't see any fly-in. In fact it behaved
exactly like it does in Windows XP/7: I had full programmatic control over the
default association by changing the registry.

What is the specific sequence of actions I can do (as a user) to trigger this
fly-in? I've never seen it before.

I'm speculating that this fly-in (not to mention all of this other "new style
Windows 8" associations logic) is just for setting the default browser (which I
understand is a Very Special Thing in Windows 8); setting other file type
handlers is still the same as always.
Yeah but we already call SHChangeNotify upon installing or updating apps so it
is already an issue. However, it does need to be taken out of here and made into
something that's called once at the top level. Ideally we'd want it to be called
once for both creating app shortcuts and associations (but that may require more
refactoring).
OK well I can't find anywhere that tells me what FLUSHNOWAIT actually does. I
must have copied it from web_app_win where we use it. We also use it in
profile_shortcut_manager_win. The Microsoft documentation
(http://msdn.microsoft.com/en-us/library/windows/desktop/bb762118.aspx) is
really unclear:

FLUSH is "The function should not return until the notification has been
delivered to all affected components."
FLUSHNOWAIT is "The function should begin delivering notifications to all
affected components but should return as soon as the notification process has
begun."

It sounds like you're always going to get one of those two behaviours, so it is
unclear what it means if you don't specify either of them. (Is there a third
possibility? Or is one of those two the default?)

I suppose it's safer to just take out FLUSHNOWAIT but I'd like to know what you
think it's for.

Anyway, this discussion will have to move to another CL, since I've just deleted
these functions. The client code will be doing the SHChangeNotify now...

[gab, 2014/10/01 14:31:11]

The default is for the notification to be buffered up and issued normally.

FLUSH makes it such that the shell is notified right-away and the method only
returns when the OS is done handling the notification.

FLUSHNOWAIT only notifies the OS right away but doesn't wait for it to be done
handling the notification.

From my experience, flushing can cause the OS to be notified of the change
before the change itself is even registered with the OS (where as not flushing
seems to ensure that the notification is queued up behind the recent changes).

Code currently using FLUSHNOWAIT is probably incorrect.

[Matt Giuca, 2014/10/02 09:36:33]

Thanks for the summary. Makes sense.

+  return true;
+}
+
+bool DeleteWindowsFileAssociations(const std::string& progid) {
+  if (!ShellUtil::DeleteFileAssociations(base::UTF8ToUTF16(progid)))
+    return false;
+
+  // Success. Tell Windows Explorer to update its cache.
+  SHChangeNotify(
+      SHCNE_ASSOCCHANGED, SHCNF_IDLIST | SHCNF_FLUSHNOWAIT, NULL, NULL);
+  return true;
+}