Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 339440 - [client] bogus layout in IE and chrome when favorites is empty
Summary: [client] bogus layout in IE and chrome when favorites is empty
Status: RESOLVED FIXED
Alias: None
Product: Orion
Classification: ECD
Component: Client (show other bugs)
Version: 0.2   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: 0.2   Edit
Assignee: Susan McCourt CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 339441 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-03-09 16:58 EST by Susan McCourt CLA
Modified: 2011-09-01 11:41 EDT (History)
2 users (show)

See Also:


Attachments
screenshot (32.46 KB, image/png)
2011-03-09 16:58 EST, Susan McCourt CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Susan McCourt CLA 2011-03-09 16:58:02 EST
Created attachment 190800 [details]
screenshot

If the favorites list is empty, then the favorites div is typically smaller than the area allocated to it by the splitter.  On chrome, this results in the dark bordercontainer background showing through.

Of course the first time anyone logs in to Orion, they have no favorites, so this is a bad first impression.
Comment 1 Susan McCourt CLA 2011-03-09 17:20:12 EST
In IE the problem was slightly different.
When you deleted the last favorite, you immediately saw the new gap appear.

On both browsers, once that large gap appears, the splitter is hosed.

Fixed in ide.css by assigning the auxpane a full width so that it takes up the whole of its splitter area.
Comment 2 Susan McCourt CLA 2011-03-09 18:14:28 EST
*** Bug 339441 has been marked as a duplicate of this bug. ***
Comment 3 Susan McCourt CLA 2011-03-09 18:16:00 EST
We had to revert this change because it caused the favorites to take up the whole screen if you didn't have a splitter cookie.  I had just changed the cookie names to fix bug 338764, so I didn't see the problem because I had cookies.  When I released both changes, no one had the cookies and saw the problem immediately.
Comment 4 Susan McCourt CLA 2011-03-09 18:16:30 EST
reopening to try alternate fix.
Comment 5 Susan McCourt CLA 2011-03-09 19:32:59 EST
Fixed.
The problem is this.  The favorites are populated via an asynchronous service call, so the border container was computing all the splitters before we know how much room we need.  In the case of having no favorites, the "Favorites progress..." string is actually longer than the list of favorites.  So what happened was:
- border container computes the sizes and places split based on progress
- content gets replaced after a service call
- border container doesn't know it, and so you get the big swath of dark gray, plus you get really weird "double splitter" behavior.

At first I was going to fix it in favorites.js by being smart and forcing a resize of the splitter.  This worked, but was not acceptable:
- favorites has to know about border containers, and either know its dom context or have its creator pass in an id
- tons of flash after favorites populated because the splitter and everything move left.

So I realized we just need to set a fixed minimum width for that pane in the HTML.  Then the splitter can layout for that size.  If the contents get larger, the user can move the splitter to see the rest.

Tested on FF, IE8, Chrome.
Note that you have to delete cookies to test this properly.  Once a splitter location is persisted, it will always use that location and you won't see the problem.