| Summary: | Creating a folder redirects to raw html page | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Szymon Brandys <Szymon.Brandys> |
| Component: | Client | Assignee: | 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
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. 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 I can confirm that it was the changes to extensionCommands.js that broke this. I am investigating. 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. 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. (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. 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. (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. |