1 (edited by free 2011-11-15 02:56:00 am)

Topic: Google Chrome Download - 'Show in folder' bug

Hi,

I encountered a problem while using LS and Chrome. I believe it it's on every system and on both 0.24.8 and 0.25.0 so this might be a ls core bug  (or chrome bug).

In short:
In the current download pannel of chrome the "Show in folder" button/link does nothing.

I wan't to ask if anyone got thois working and if not then I'd like to report this as a core bug.

2 (edited by the-golem 2011-11-15 04:50:01 am)

Re: Google Chrome Download - 'Show in folder' bug

free wrote:

Hi,

I encountered a problem while using LS and Chrome. I believe it it's on every system and on both 0.24.8 and 0.25.0 so this might be a ls core bug  (or chrome bug).

In short:
In the current download pannel of chrome the "Show in folder" button/link does nothing.

I wan't to ask if anyone got thois working and if not then I'd like to report this as a core bug.

This has absolutely nothing to do with LiteStep. There's no fathomable way that LiteStep could interfere with or modify how a webpage functions.  The "Show in folder" link doesn't have a href/url attached to it.

No url, no worky.

3

Re: Google Chrome Download - 'Show in folder' bug

Then why does it work when using default windows shell?

4

Re: Google Chrome Download - 'Show in folder' bug

This might actually be related to the "run as shell" LS option

5

Re: Google Chrome Download - 'Show in folder' bug

Sounds like a core bug to me. There are a lot of bugs like it. This can be added to the long line of "mystery bugs". See http://www.lsdev.org/bugs/view.php?id=68

6 (edited by free 2011-11-15 12:46:15 pm)

Re: Google Chrome Download - 'Show in folder' bug

Tobbe wrote:

This might actually be related to the "run as shell" LS option

Do you reffer to the LSSetAsShell option? If so then this does not fix the problem. Instead it makes windows file manager not refresh it's view when moving/creating/deleting files even in conjunction with LSUseSystemDDE.

I'd connect this bug with http://www.lsdev.org/bugs/view.php?id=68

7

Re: Google Chrome Download - 'Show in folder' bug

Yes, it is known that LSSetAsShell causes all kinds of weird behavior. That's why it isn't on by default. But it also fixes some other weird behavior, and I thought it might fix this for you. Apparently it doesn't sad

8

Re: Google Chrome Download - 'Show in folder' bug

Tobbe wrote:

Yes, it is known that LSSetAsShell causes all kinds of weird behavior. That's why it isn't on by default. But it also fixes some other weird behavior, and I thought it might fix this for you. Apparently it doesn't sad

I still think this is a Chrome problem. There have been reports of that exact link not working across multiple platforms, including Google's own ChromeOS and folks using XP.

9

Re: Google Chrome Download - 'Show in folder' bug

I remember some other programs have same problem with litestep but can't remember which ones :S. So it's most likely some weird way to call windows explorer which litestep doesn't handles correctly

10

Re: Google Chrome Download - 'Show in folder' bug

Opera has the same problem, though IE8 works fine.

11

Re: Google Chrome Download - 'Show in folder' bug

The same happens with windows file properties window when you click on the 'find soulrce file' or whatever it's named in english.

12

Re: Google Chrome Download - 'Show in folder' bug

Nevermind, doesn't work in IE8.
Weird, it appears as if the web browser is sending a command to litestep that is foreign.

13

Re: Google Chrome Download - 'Show in folder' bug

Chrome is open source wink If you could find the line of code that is supposed to show the folder we could probably find a fix for it!

14

Re: Google Chrome Download - 'Show in folder' bug

Tobbe wrote:

Chrome is open source wink If you could find the line of code that is supposed to show the folder we could probably find a fix for it!

Here's the JS function that creates the link:

// We don't need "show in folder" in chromium os. See download_ui.cc and
// http://code.google.com/p/chromium-os/issues/detail?id=916.
var showinfolder = localStrings.getString('control_showinfolder');
if (showinfolder) {
    this.controlShow_ = createLink(this.show_.bind(this), showinfolder);
    this.nodeControls_.appendChild(this.controlShow_);
} else {
    this.controlShow_ = null;
}

The snippet suggests that download_ui.cc might be the file to look at, but it's proving difficult to locate

15

Re: Google Chrome Download - 'Show in folder' bug

I think download_ui.cc contains the "show in folder" link, not the function itself.

It's probably easier to sniff the function call Chrome makes than to debug it.

16

Re: Google Chrome Download - 'Show in folder' bug

Stuff that might be helpful:

http://codereview.chromium.org/506045/d … oads_ui.cc

http://src.chromium.org/viewvc/chrome/t … iew=markup

17

Re: Google Chrome Download - 'Show in folder' bug

Maybe i'm confused but why did they update showinfolder like that when they define the bool true when either running chrome os or when not running chrome os. -_-

Anyway, like i said. Catching the call is probably easier than plowing the code wink

18 (edited by Tobbe 2011-11-25 21:43:37 pm)

Re: Google Chrome Download - 'Show in folder' bug

As the-golem said, it all starts with this:

// We don't need "show in folder" in chromium os. See download_ui.cc and
// http://code.google.com/p/chromium-os/issues/detail?id=916.
var showinfolder = localStrings.getString('control_showinfolder');
if (showinfolder) {
    this.controlShow_ = createLink(this.show_.bind(this), showinfolder);
    this.nodeControls_.appendChild(this.controlShow_);
} else {
    this.controlShow_ = null;
}

Further down in downloads.html you have this:

/**
 * Tells the backend to show the file in explorer.
 */
Download.prototype.show_ = function() {
  chrome.send("show", [this.id_.toString()]);
  return false;
}

From now on I'll just let the code speak mostly for itself:

chrome/browser/ui/webui/downloads_dom_handler.cc

  web_ui_->RegisterMessageCallback("show",
      base::Bind(&DownloadsDOMHandler::HandleShow,
                 base::Unretained(this)));

// Further down
void DownloadsDOMHandler::HandleShow(const ListValue* args) {
  CountDownloadsDOMEvents(DOWNLOADS_DOM_EVENT_SHOW);
  DownloadItem* file = GetDownloadByValue(args);
  if (file)
    file->ShowDownloadInShell();
}

content/browser/download/download_item_impl.cc

void DownloadItemImpl::ShowDownloadInShell() {
  // TODO(rdsmith): Change to DCHECK after http://crbug.com/85408 resolved.
  CHECK(BrowserThread::CurrentlyOn(BrowserThread::UI));

  content::GetContentClient()->browser()->ShowItemInFolder(GetFullPath());
}

chrome/browser/chrome_content_browser_client.cc

void ChromeContentBrowserClient::ShowItemInFolder(const FilePath& path) {
  platform_util::ShowItemInFolder(path);
}

Looks like we're getting closer... smile

chrome/browser/platform_util_win.cc

void ShowItemInFolder(const FilePath& full_path) {
  DCHECK(BrowserThread::CurrentlyOn(BrowserThread::UI));
  BrowserThread::PostTask(BrowserThread::FILE, FROM_HERE,
      base::Bind(&ShowItemInFolderOnFileThread, full_path));
}

//Higher up in the same file

void ShowItemInFolderOnFileThread(const FilePath& full_path) {
  DCHECK(BrowserThread::CurrentlyOn(BrowserThread::FILE));
  FilePath dir = full_path.DirName();
  // ParseDisplayName will fail if the directory is "C:", it must be "C:\\".
  if (dir.value() == L"" || !file_util::EnsureEndsWithSeparator(&dir))
    return;

  typedef HRESULT (WINAPI *SHOpenFolderAndSelectItemsFuncPtr)(
      PCIDLIST_ABSOLUTE pidl_Folder,
      UINT cidl,
      PCUITEMID_CHILD_ARRAY pidls,
      DWORD flags);

  static SHOpenFolderAndSelectItemsFuncPtr open_folder_and_select_itemsPtr =
    NULL;
  static bool initialize_open_folder_proc = true;
  if (initialize_open_folder_proc) {
    initialize_open_folder_proc = false;
    // The SHOpenFolderAndSelectItems API is exposed by shell32 version 6
    // and does not exist in Win2K. We attempt to retrieve this function export
    // from shell32 and if it does not exist, we just invoke ShellExecute to
    // open the folder thus losing the functionality to select the item in
    // the process.
    HMODULE shell32_base = GetModuleHandle(L"shell32.dll");
    if (!shell32_base) {
      NOTREACHED() << " " << __FUNCTION__ << "(): Can't open shell32.dll";
      return;
    }
    open_folder_and_select_itemsPtr =
        reinterpret_cast<SHOpenFolderAndSelectItemsFuncPtr>
            (GetProcAddress(shell32_base, "SHOpenFolderAndSelectItems"));
  }
  if (!open_folder_and_select_itemsPtr) {
    ShellExecute(NULL, L"open", dir.value().c_str(), NULL, NULL, SW_SHOW);
    return;
  }

  base::win::ScopedComPtr<IShellFolder> desktop;
  HRESULT hr = SHGetDesktopFolder(desktop.Receive());
  if (FAILED(hr))
    return;

  base::win::ScopedCoMem<ITEMIDLIST> dir_item;
  hr = desktop->ParseDisplayName(NULL, NULL,
                                 const_cast<wchar_t *>(dir.value().c_str()),
                                 NULL, &dir_item, NULL);
  if (FAILED(hr))
    return;

  base::win::ScopedCoMem<ITEMIDLIST> file_item;
  hr = desktop->ParseDisplayName(NULL, NULL,
      const_cast<wchar_t *>(full_path.value().c_str()),
      NULL, &file_item, NULL);
  if (FAILED(hr))
    return;

  const ITEMIDLIST* highlight[] = {
    {file_item},
  };

  hr = (*open_folder_and_select_itemsPtr)(dir_item, arraysize(highlight),
                                          highlight, NULL);

  if (FAILED(hr)) {
    // On some systems, the above call mysteriously fails with "file not
    // found" even though the file is there.  In these cases, ShellExecute()
    // seems to work as a fallback (although it won't select the file).
    if (hr == ERROR_FILE_NOT_FOUND) {
      ShellExecute(NULL, L"open", dir.value().c_str(), NULL, NULL, SW_SHOW);
    } else {
      LPTSTR message = NULL;
      DWORD message_length = FormatMessage(
          FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM,
          0, hr, 0, reinterpret_cast<LPTSTR>(&message), 0, NULL);
      LOG(WARNING) << " " << __FUNCTION__
                   << "(): Can't open full_path = \""
                   << full_path.value() << "\""
                   << " hr = " << hr
                   << " " << reinterpret_cast<LPTSTR>(&message);
      if (message)
        LocalFree(message);
    }
  }
}

So solving this bug: http://www.lsdev.org/bugs/view.php?id=60 will probably solve this problem as well

19

Re: Google Chrome Download - 'Show in folder' bug

Wow, Tobbe. Excellent work! Guess it was a LiteStep bug afterall :-(

20

Re: Google Chrome Download - 'Show in folder' bug

Good find Tobbe. That using that stuff you posted on the bugbtracker should make it easy to implement.

21

Re: Google Chrome Download - 'Show in folder' bug

It might not be so easy as you think. Working with COM is a pain!

Basically we need to have a "shell window", whatever that is, that can be queried for a IWebBrowserApp. A IWebBrowserApp is basically a COM interface to Internet Explorer, I use that for my LSActiveDesktop module but I'm not sure I got it right. I think it's leaking COM objects. The IWebBrowserApp needs a Document that has a IShellFolderViewDual, which I have no idea how to set up.

But please, Acidfire, do go ahead and fix it! big_smile

22

Re: Google Chrome Download - 'Show in folder' bug

well, anyone tried replace the filemanager? i'm using explorer++ ( just like notepad++) and it can replace the default opening action in its settings. i've already changed my os to win8, but if can remember well, Google Chrome works with explorer++.