Bugzilla – Full Text Bug Listing
| Summary: | [client] bogus layout in IE and chrome when favorites is empty | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Susan McCourt <susan> | ||||
| Component: | Client | Assignee: | Susan McCourt <susan> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | john.arthorne, simon_kaegi | ||||
| Version: | 0.2 | ||||||
| Target Milestone: | 0.2 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
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. *** Bug 339441 has been marked as a duplicate of this bug. *** 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. reopening to try alternate fix. 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. |
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.