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

Bug 391819

Summary:	New File/Folder button after previous uses input area below failure message
Product:	[ECD] Orion	Reporter:	Ken Walker <ken_walker>
Component:	Client	Assignee:	Susan McCourt <susan>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	leejcj
Version:	0.5	Keywords:	helpwanted
Target Milestone:	3.0 M1	Flags:	leejcj: review?
Hardware:	All
OS:	All
Whiteboard:

Description Ken Walker

2012-10-12 13:56:47 EDT

Go into a folder.  Press the "New File" and create "aaa".

Now Press "New File" and again enter "aaa".

You should get an error. Do NOT clear the Error with the X.

Press "New File" and see where the input area goes below the error.

Comment 1 Jason Lee

2012-11-15 20:58:34 EST

I have made a commit that fixes this bug and would like it to be reviewed.  This is my first time using github to commit to a project so I apologize in advance if I made the world crumble.  Any feedback would be appreciated.

https://github.com/jcjlee/orion.client.git
Branch Name: Bug391819
Commit ID: 70785d40ab8cd727b5066a9a3730691ffb40adf4

Comment 2 Susan McCourt

2012-11-16 11:22:50 EST

thanks, Jason...I will take a look at this one, hopefully today and if not, then early next week.

Comment 3 Susan McCourt

2012-11-29 12:55:32 EST

hi, Jason, sorry this took so long.
I took a look at the patch, but unfortunately this solution is a bit too specific to the problem.

The status service is used on every single Orion page, so a solution where we look for specific button ids (new file/new folder) is not going to work on other pages.  Also, the id's for those buttons can change (note the index numbers on the end of the button id) as the implementation evolves.

I think we need a more generic solution where the CSS/layout gets fixed in the case where a parameter slideout and an error message are showing, otherwise we would see this problem anytime an error and slideout are present.

The place to look in the code is globalCommands.js, the function "layoutToolbarElements" 
This is where the computation of the heights needed to show error, slideout, and the content area are done. 

This is not the simplest code to understand (my fault) so please ping here if you have any questions about it.  For a solution, we'd want to see that the problem is fixed as well as ensure any progress messages/error reporting are also still working.  A similar bug I fixed is bug 391596.  The commit is
http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=d68c86cbac929f05bddfad54ac5beec124e71969

Comment 4 Jason Lee

2012-12-03 12:45:00 EST

Hi.  Thanks for the feedback, Susan. I think this version is closer to what you were hoping for.  I changed the margin generation in layoutToolbarElements to use the height of the .slideContainerActive element when adding to heightExtras.    Explorer tree's empty table header now maintains the same 8px margin from the bottom of the lowest active slidecontainer div, regardless of if 0, 1, or 2 are active.  Tested in chrome and firefox. 

git://github.com/jcjlee/orion.client.git
branch name: bug391819_newfix
Commit ID: 348a569ca8db574ed49d77a5e33736f010f17c0d

Comment 5 Susan McCourt

2013-03-12 11:43:35 EDT

There has been a ton of rework in this area while removing dijit and again when cleaning up the command service.

I believe this to be fixed now (there was a not a screenshot attached to show the problem but I recall that we didn't leave enough space for both the message and the input area, and things drifted downward).  

As it is now, I think the behavior is correct.  The input area will always appear below the message area if there is an active message, but it is layed out correctly and if you close either one, it shifts properly.  There is no drift.