Community
Participate
Working Groups
with all the structural and styling changes for the new look, I think some old "overflow" bugs are back. For example: - left hand pane in navigator has a vertical scrollbar even when not needed. If you expand/collapse the splitter, it fixes itself. I remember having to add code to eWebBorderContainer to remember and reset overflow back in 0.2. Check old bugs and code history. - git status left hand pane does not grow the vertical scrollbar when the git logs come in, so you can't scroll until you resize. - unrelated but weird: it seems like the ewebbordercontainer collapse arrows are reversed.
*** Bug 369971 has been marked as a duplicate of this bug. ***
I had a look at some of this. > - left hand pane in navigator has a vertical scrollbar even when > not needed. If you expand/collapse the splitter, it fixes itself. > I remember having to add code to eWebBorderContainer to > remember and reset overflow back in 0.2. Check old bugs > and code history. this appears to be the code in the eWebSplitter._handleOnChange function. It is copied from ToggleSplitter I think and retains this bit: var styleProps = dojo.mixin({ display: "block", overflow: "auto", visibility: "visible" }, this._openStyleProps); The inclusion of overflow:auto appears to override the hidden settings specified elsewhere (css). If you remove the overflow line there, it behaves correctly. There is no duplicate vertical scroll bar. (the scrollbar from the internal content pane is used) I've got a commit for it, but it feels overkill for just removing that one line! git repo: https://github.com/aclement/orion.client branch: bug369890 commit id: 419dee775f587b02c581f0e9e8c8cf86b35a7f84 full link: https://github.com/aclement/orion.client/commit/419dee775f587b02c581f0e9e8c8cf86b35a7f84 I'm no expert on this area of the code though so might be wrong, but that change did fix it for me. > - unrelated but weird: it seems like the ewebbordercontainer collapse arrows > are reversed. I know what you mean - I puzzled over this for a while but eventually concluded that the arrow was reflecting the state of the pane, not what would happen if you click on it. (so it was a right arrow icon when open and a left arrow icon when closed). (if that is what you were seeing...)
(In reply to comment #2) > I had a look at some of this. > I've got a commit for it, but it feels overkill for just removing > that one line! Yes, but a well placed line makes all the difference! Thanks for looking into this. The code I was remembering adding had to do with remembering the current overflow on close and restoring on open. You are right that the other part was subverting the attempt to honor the original CSS. I pushed the fix. Thanks again! > I know what you mean - I puzzled over this for a while but eventually concluded > that the arrow was reflecting the state of the pane, not what would happen if > you click on it. (so it was a right arrow icon when open and a left arrow icon > when closed). (if that is what you were seeing...) Yes. They should show you what will happen. I think the current way is not intentional, it's one of those toggle things that's easy to get wrong when the names are things like "open/closed" or "left/right" rather than "openIt/closeIt" or "moveLeft/moveRight". I swapped the images in the CSS.
fixed. Tested on Chrome 16, FF 9, IE9
