Bugzilla – Full Text Bug Listing
| Summary: | [client] Hidden panes don't have a scroll when closed while loading | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Malgorzata Janczarska <malgorzata.tomczyk> | ||||
| Component: | Client | Assignee: | Malgorzata Janczarska <malgorzata.tomczyk> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | susan | ||||
| Version: | 0.2 | Flags: | susan:
review+
|
||||
| Target Milestone: | 0.2 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Malgorzata Janczarska
This issue applies to every hiding pane including favorites and editor outline. This is how it can be reproduced: 1. Load the page with the hiding pane (editor, navigator...) 2. Close the pane (outline, navigator...) 3. Reload the page 4. The pane is closed by default [GOOD] 5. Open the pane 6. Resize the window or pane so that its content doesn't fit and scroll would be needed 7. Scroll is missing [BUG] Created attachment 197383 [details]
Removed changing overflow
It occurred that when on loading the hiding pane was closed its overflow was by default changed to "hidden". This was made in the same place where its visibility was changed to "hidden". See use of _getStyleProps from ToggleSplitter in eWebBorderContainer.js#eWebSplitter#__handleOnChange (line 221).
Because changing overflow isn't really necessary when the pane is hidden I think we can omit this step and keep the overflow set in the page style. I tested it on favorites, editor outline and commit details and it solves the problem and doesn't seem to break anything.
I need a review to push this change. This is kind of a follow-on to bug 343288. In that bug, I noticed that our eWebBorderContainer code (probably originally copied from ToggleSplitter) was slamming the overflow. This was causing the navigator horizontal scrollbar to disappear. (I wish I had written a better description/symptoms in that bug.) I added code to keep track of what the overflow should be. But as you have observed, on page reload, the "what was my overflow" variable is no longer set, the startup code will call the _handleOnChange, which will call the _getStyleProps, and the overflow will get slammed. I don't like the fact that we are now hacking in dojox code to fix bugs. Because we'll lose this fix when we move to a different dojo. On the other hand, copying the whole method to eWebBorderContainer in order to retain the fix will also be problematic when changing dojo. So...+1 on the fix because the symptom is quite bad, esp. in the git log views where we are opening/closing the splitter for the user and exacerbating the bug. But it gives us one more reason to try to get rid of this eWebBorderContainer, or at least move away from the dojo implementation and just rewrite it. I put a pointer to this bug in 343915. changed pushed. |