Hi Bono-san, Thanks for your response. I think your resolution has some problems:
- There is a nasty timing issue; The user faces the same problem if the user opens the menu, somebody deletes the file after that, and then the user clicks the menu item. - There is no way to know the reason why the menu is disabled. - You can still open the item by clicking the button (when should we disable it?). - chrome://downloads/ still has the problem. I feel that we need to display some feedback of ShellOpen. Opening a file without checking sounds horrible to me. Thanks, Yuta 2009/05/22 20:40 Hironori Bono (坊野 博典) <[email protected]>: > Hi Yuta, > > I suspect it is simpler to change > DownloadShelfContextMenu::IsItemCommandEnabled() and enable its "open" > and "show in folder" items only when the downloaded file exists as > shown in my mock code <http://codereview.chromium.org/113805>. (Even > though this mock code is not tested thoroughly and may cause > side-effects, please feel free to copy and use it.) > > Regards, > > Hironori Bono > E-mail: [email protected] > > On Sat, May 23, 2009 at 10:47 AM, Yuta Kitamura <[email protected]> wrote: > > Hi all, > > I've been researching on DownloadManager for a day in order to to fix the > > issue 3551 <http://crbug.com/3551>. I want to hear some advice from > people > > who know Chrome's design well. > > The problem of this issue is like the > > following: DownloadManager::OpenDownloadInShell() posts a task that opens > a > > file using the shell (ShellExecute()) to the file thread. Because this > task > > does not return any response (i.e. whether open was successful or not) > back > > to the UI thread, DownloadItem cannot receive the result of open and the > > browser UI cannot display it either. > > So, I want to add the functionality of receiving the result of opening a > > file to DownloadItem. My current idea of implementation is: > > 1. Let DownloadItem be RefCountedThreadSafe, and rewrite use of > > "DownloadItem*" to "scoped_refptr<DownloadItem>". > > 2. Add the interface of receiving the result of OpenDownloadInShell to > > DownloadItem. Modify DownloadFileManager::OnOpenDownloadInShell to pass > the > > result to it. > > 3. Modify UI (DownloadItemView) to reflect these changes. > > 4. Write tests. > > My question is: > > - How do you think about the whole idea? Am I going the right way? > > - Step 1: Is it okay to do this? Will this change give the negative > effect > > of the browser's speed? > > - Step 3: How should the UI look like? > > - Step 4: How to do it? Is there a good reference in the existing tests? > > (Sorry but I'm not very experienced on testing...) > > How do you think? Any idea and suggestion is welcome! > > Thanks, > > Yuta > > > > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
