Community
Participate
Working Groups
0.3 RC2 at times it can take over 3 seconds for the UI to update on a new file/new folder operation. We should use the progress service so the user sees something is happening.
investigate for rc3
Strange that it takes so long. The network communication for me is only 200-300ms (using orion.eclipse.org from home). But I agree in general any file operation could potentially take a long time so a message giving feedback that it's running would be helpful (I wouldn't actually expect it to report meaningful progress).
(In reply to comment #2) > Strange that it takes so long. The network communication for me is only > 200-300ms (using orion.eclipse.org from home). But I agree in general any file > operation could potentially take a long time so a message giving feedback that > it's running would be helpful (I wouldn't actually expect it to report > meaningful progress). I was also using orion.eclipse.org from home. Not sure what your home connection is like, mine is 1.5Mbps (believe it or not this is the fastest speed currently available on DSL where I live) I was having some timeouts (possible hiccups) earlier today when I saw this. Just retried, and while the navigator seems more responsive, it's still about 2 seconds from hitting enter on a file name to updating the UI. About the same for deletes as well.
proposed fix is in remote branch origin/bug361006 I added progress handling for new file, new folder, new project, delete, and link project. I think it helps a lot, on my home network I can have 2-3 second lags and often wonder if anything is happening. The downside to this patch is that if there is an error, the progress message could be left dangling in the progress area. See bug 361293. Since the easiest thing to get an error with is link, maybe we shouldn't implement progress handling for link until we can get the errors reported correctly.
John, could you review the code in remote branch origin/bug361006? Simon, adding you for approving that we should fix this. If indeed we are swallowing service errors (bug 361293) we may want to remove the progress handling for link, since it's not enabled on orionhub, orion.eclipse.org, and therefore you'll always get an error and "stuck" progress message.
So with this change, error reporting for file/folder creation/deletion is broken, whereas before this was displaying fine. For example, trying create a file/folder that already exists, or contain an invalid character. In master this correctly shows an error message in the status area, but with your branch you just get hanging progress forever. The progress reporting does look very nice. But, considering that is a cosmetic improvement, vs losing error messages which are important function, I don't like that trade-off.
Yep, similar feeling to John. Rather have the broken I know than the broken I don't. I'll try to look at bug 361293 tomorrow to see if there is a root problem blocking this.
> So with this change, error reporting for file/folder creation/deletion is > broken, whereas before this was displaying fine. For example, trying create a > file/folder that already exists, or contain an invalid character. In master > this correctly shows an error message in the status area, but with your branch > you just get hanging progress forever. > > The progress reporting does look very nice. But, considering that is a cosmetic > improvement, vs losing error messages which are important function, I don't > like that trade-off. oh, my, this is why we do reviews! I would never have proposed this change if I realized that it caused errors to be swallowed that were being reported before. I was using "Link Folder" as my test case for error reporting, which is behaving differently (why?) In the current build, the link errors are reported with that funny dialog. With the change, you get the funny dialog (and the hanging progress message) but you still get the error. I did not realize that (some types of) errors were completely being swallowed by progress service after this change. I'll leave the milestone set for now, in case we decide the blocking bug is actually worth fixing, but I'm assuming for now that this will come in later.
Ok, I understand now. Bug 361293 and the "Link Folder" scenario was a special case/red herring involving the auth plugin. The swallowing of the error case for "new folder" and others appears to be a misunderstanding on my part about error handling when the progress manager is in charge. I thought the progress handler would dispatch errors, but it does not. I changed patterns like this: fileClient.createFolder(item.Location, name).then( dojo.hitch(explorer, function() {this.changedItem(item);}), function(error) { serviceRegistry.getService("orion.page.message").then( function(statusService) { statusService.setErrorMessage(error); }); }); to: serviceRegistry.getService("orion.page.message").then( function(progressService) { var deferred = fileClient.createFolder(item.Location, name); progressService.showWhile(deferred, "Creating folder " + name + "...").then( dojo.hitch(explorer, function() {this.changedItem(item);})); }); Instead, we would need to do something like: serviceRegistry.getService("orion.page.message").then( function(progressService) { var deferred = fileClient.createFolder(item.Location, name); progressService.showWhile(deferred, "Creating folder " + name + "...").then( dojo.hitch(explorer, function() {this.changedItem(item);}), function(error) { serviceRegistry.getService("orion.page.message").then( function(statusService) { statusService.setErrorMessage(error); }); ); }); That last expression seems unnecessarily complicated and error-prone. Instead, we could ensure the progress handler provides an errback that does the right thing, since it is the error reporter anyway. I changed the progress handler to do this, and the correct thing happens for new file and folder. I pushed it to the remote branch origin/bug361006, just to save the thought. However I'm not sure this is the correct solution, and we need to look at how other progress operations are doing this (such as in git). So I'm assigning this bug to 0.4 and will talk to John about what we think the progress handler should be doing.
move and copy need progress handlers also. There is a long enough pause that one wonders if it's working
would also be good to have one for "reload plugins"
Maybe we should have setProgressResult/Message(display, delay)? Then the body of each command could be like: setProgressMessage("Creating file", 3000); ... some logic setProgressResult("");
moving out of 0.5M2 to 0.5 milestone until we have more specific buckets for future
*** Bug 388826 has been marked as a duplicate of this bug. ***
check all folder operations, such as delete...
I added progress handlers to new file and new folder while working on the "create new content" support in bug 378749. However I want to keep this bug open in RC1 for general testing of navigator file operations, both for progress, and to make sure no error handlers have been swallowed.
Fixed with http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=db066a7718c0d9412ed56bb42bef2e73d8f709ac. Added progress handlers to rename, delete, link project, move/copy. With the recent server slowdowns, I thought it best to provide progress on all the file operations. Tested that progress is reported correctly. Tested error reporting for new file, folder, project, link, import, move, copy.
