Be explicit about target type in platform_util::OpenItem()

ui/base/win/shell.h

Index: ui/base/win/shell.h
diff --git a/ui/base/win/shell.h b/ui/base/win/shell.h
index 3b64ce7dca289ef68b28e06b4dbbab271f330a98..4031de6d9aec479411001681081c928964e61624 100644
--- a/ui/base/win/shell.h
+++ b/ui/base/win/shell.h
@@ -17,16 +17,29 @@ class FilePath;
 namespace ui {
 namespace win {
 
-// Open or run a file via the Windows shell. In the event that there is no
-// default application registered for the file specified by 'full_path',
-// ask the user, via the Windows "Open With" dialog.
-// Returns 'true' on successful open, 'false' otherwise.
-UI_BASE_EXPORT bool OpenItemViaShell(const base::FilePath& full_path);
+// Open the folder at |full_path| via the Windows shell. Does nothing if
+// |full_path| is not a folder.
+//
+// Note: Must be called on a thread that allows blocking.
+UI_BASE_EXPORT bool OpenFolderViaShell(const base::FilePath& full_path);
+
+// Invokes the default verb on the file specified by |full_path| via the Windows
+// shell. Usually, the default verb is "open" unless specified otherwise for the
+// file type.
+//
+// In the event that there is no default application registered for the
+// specified file, asks the user via the Windows "Open With" dialog.  Returns
+// |true| on success.
+//
+// Note: Must be called on a thread that allows blocking.
+UI_BASE_EXPORT bool OpenFileViaShell(const base::FilePath& full_path);
 
 // Lower level function that allows opening of non-files like urls or GUIDs
 // don't use it if one of the above will do. |mask| is a valid combination
-// of SEE_MASK_FLAG_XXX as stated in msdn. If there is no default application
-// registered for the item, it behaves the same as OpenItemViaShell.
+// of SEE_MASK_XXX as stated in MSDN. If there is no default application
+// registered for the item, it behaves the same as OpenFileViaShell.
+//
+// Note: Must be called on a thread that allows blocking.

[sky, 2015/03/06 18:21:33]

The synchronous/blocking nature of this code is new. Are all existing call sites
able to deal with the new behavior?

[asanka, 2015/03/06 21:09:40]

Yeah. They are able to deal. The callers are platform_util (which calls
Open*ViaShell on the blocking pool), shell_handler_win (runs in main thread of
utility process), and first_run_internal_win (runs prior to setting up browser
process threads).

The blocking nature isn't completely new. The SEE_MASK_NOASYNC flag to
ShellExecuteEx() is identical to the SEE_MASK_FLAG_DDEWAIT flag that was used
with the "openas" verb (same numerical value). The behavior is explicitly
documented now along with enforcement via a ThreadRestrictions check. In
addition, the NOASYNC/DDEWAIT flag is now used deterministically instead of only
being used when a suitable handler was not found for the file.

 UI_BASE_EXPORT bool OpenAnyViaShell(const base::string16& full_path,
                                     const base::string16& directory,
                                     const base::string16& args,