Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 445677

Summary: Creating a folder redirects to raw html page
Product: [ECD] Orion Reporter: Szymon Brandys <Szymon.Brandys>
Component: ClientAssignee: Curtis Windatt <curtis.windatt.public>
Status: RESOLVED FIXED QA Contact:
Severity: major    
Priority: P3 CC: curtis.windatt.public, mamacdon
Version: unspecified   
Target Milestone: 7.0   
Hardware: PC   
OS: Windows 7   
Whiteboard:

Description Szymon Brandys CLA 2014-10-01 11:14:04 EDT
To reproduce just create a folder in a project. I am on FF.
Comment 1 Szymon Brandys CLA 2014-10-01 11:15:22 EDT
I was redirected to http://localhost:8082/cc/file/sbrandys-OrionContent/sbrandys%20|%20SampleGit/something/ where 'something' is the name of newly created folder. The folder is created btw.
Comment 2 Mark Macdonald CLA 2014-10-01 11:47:24 EDT
Bisected to this commit

cc4396138cecd50f731b87940f06cbd333a6dc73 is the first bad commit
commit cc4396138cecd50f731b87940f06cbd333a6dc73
Author: Curtis Windatt <cwindatt@ca.ibm.com>
Date:   Thu Sep 25 15:35:43 2014 -0400

    Bug 444531 - extensionCommands.js needlessly validates every command for a directories visible in the navigator
Comment 3 Curtis Windatt CLA 2014-10-01 12:17:52 EDT
I can confirm that it was the changes to extensionCommands.js that broke this.  I am investigating.
Comment 4 Mark Macdonald CLA 2014-10-01 12:37:25 EDT
So my claim a while ago that directories didn't get processed with the contentType infrastructure was wrong. The "open with orion editor" command is assigned a content type of "*/*", which is expected to match directories -- see extensionCommands.js lines 90-95.

If the "Open in Orion Editor" command does not match, then after creating a folder, setup.js finds the "open in web browser" command instead, and takes you to the folder URL.
Comment 5 Curtis Windatt CLA 2014-10-01 13:32:32 EDT
http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=e6105c650330b7edf8f18097dce6f5a2372e95bc
Pushed a fix to master
Now if the content type '*/*' is found we will validate the command against directories.  Note that the wiki page for commands suggests that you cannot validate a content type against a directory.

I didn't see anywhere this was covered by tests.

There are other possible fixes, I'll do some investigation:
1) Find another way to determine how to open an item after it is created (see setup.js, shellPage.js and navigatorRenderer.js
2) If the open with command applies to everything, it shouldn't be restricted to a content type at all.
3) Add an option to the commands framework to allow a 'directory' content type.
Comment 6 Curtis Windatt CLA 2014-10-01 16:33:01 EDT
(In reply to Curtis Windatt from comment #5)
> 2) If the open with command applies to everything, it shouldn't be
> restricted to a content type at all.

We can make this work by removing the addition of */* to the content types and tweaking the logic when validating.  If a command has no required content types and no excluded content types, it is valid (this exists already in my logic).  If a command has no required content types, but has excluded types, directories are valid (not true currently).

The openWithCommand has no included content types, but it does have an excluded type of image/*.  Commands like this would have to be valid for directories.

While I have this code working in my workspace, I don't think it makes sense to change the logic this way.

> 3) Add an option to the commands framework to allow a 'directory' content
> type.

I think moving partway towards this is the best solution.  We treat */* as meaning everything, including directories.  So if it is in the includes, it is valid, if it is in the excludes it is invalid (when the selection is a directory). I don't think we should go as far as make it explicit in the API.
Comment 7 Curtis Windatt CLA 2014-10-01 16:44:28 EDT
http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=58d49e875a8fc91b70a0f6633fcacb5bfcb9beaa
Additional fix in master

This updates the logic to be better performing.  If a directory is selected, a command will only be valid for it if and only if */* is in its content type.  This is not stated in the wiki as it is only used internally for the openWithCommand.
Comment 8 Curtis Windatt CLA 2014-10-01 16:48:07 EDT
(In reply to Curtis Windatt from comment #7)
> This updates the logic to be better performing.  If a directory is selected,
> a command will only be valid for it if and only if */* is in its content
> type.  This is not stated in the wiki as it is only used internally for the
> openWithCommand.

One extra footnote:
If a command has no required content types, but does have excluded content types, the logic will now mark the command invalid for directories.