Opened 12 years ago
Closed 9 years ago
#9449 closed defect (fixed)
test_BorderContainer: unexpected scrollbars in Safari 4
Reported by: | haysmark | Owned by: | bill |
---|---|---|---|
Priority: | high | Milestone: | 1.4 |
Component: | Dijit | Version: | 1.3.1 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description
In test_BorderContainer, go down to the very simply styled "More fun with layouts" BorderContainer?. If you move the leftmost vertically aligned spacer just a little, all of the sudden all of the BorderContainers? are filled with scrollbars, even if you move the bar back to its original location. Observed on Safari 4 on Windows but haven't tested Mac.
Attachments (3)
Change History (27)
comment:1 Changed 12 years ago by
Milestone: | tbd → 1.4 |
---|
comment:2 Changed 12 years ago by
comment:3 Changed 11 years ago by
Owner: | changed from Adam Peller to bill |
---|---|
Status: | new → assigned |
Doesn't happen on chrome for me, just safari.
I think it's to do with those intermediate ContentPane's that contain a single BorderContainer child. I'm seeing the ContentPane with width=150 but it's child BorderContainer with width=160.
comment:5 Changed 11 years ago by
comment:6 Changed 11 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
(In [20079]) Use overflow:hidden for ContentPanes? w/a single layout child, to avoid safari bugs.
Fixes #9449 !strict.
comment:7 Changed 11 years ago by
comment:8 Changed 11 years ago by
comment:9 Changed 11 years ago by
comment:11 Changed 11 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
The fix (setting overflow:hidden) in [20079] causes breakage in the i18n demo.
The problem is that scrollbars no longer appear on a ContentPane? within a BorderContainer? when it has a single child widget (like the tree on the left-hand side).
comment:12 Changed 11 years ago by
The problem is that scrollbars no longer appear on a ContentPane within a BorderContainer when it has a single child widget (like the tree on the left-hand side).
Basically that's correct behavior (and the intention of the patch). When ContentPane contains a single layout widget as it's child, the ContentPane shouldn't display a scrollbar.... the idea being that the underlying widget itself will supply it's own scrollbar (or it will do something so that there's no need for a scrollbar).
The actual test that ContentPane does is whether the underlying widget has a resize() method. Tree breaks this pattern since it has a resize() method but that resize() method doesn't even take a size parameter.
comment:13 Changed 11 years ago by
PS: when I wrote "layout widget" above I should have actually wrote something like "sizable widget". A ContentPane will size an Editor or Grid equally as well as a TabContainer, BorderContainer, etc. Anything that can be a child of a layout container can function as a "single child" of ContentPane.
comment:14 Changed 11 years ago by
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
comment:15 Changed 11 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
It's still not quite there...the scrollbars now appear for each "sub-tree" on the same example (http://archive.dojotoolkit.org/nightly/checkout/demos/i18n/demo.html)
To see open make the left-hand pane narrow enough that when you open Antarctica the left/right scrollbar appears. Scrolling this *ONLY* scrolls the "Antarctica" block. This gets really confusing if you open two different blocks (i.e. North America and Antarctica) where they *each* have their own horizontal scroll bars, and they each scroll separately.
This is a completely different from how it behaved before these changes.
comment:16 Changed 11 years ago by
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
comment:17 Changed 11 years ago by
I'm still not quite sold on this solution either...(though probably not enough to reopen the bug...). Previously, the scroll bars would show up as part of the content pane...now, they show up as part of the child...which means that there is, by default, a 5px padding between the scroll bars and the content pane. (see the previously attached screenshot)
I just think it "looks" a bit sloppier than having the scroll bars as a part of the content pane.
Changed 11 years ago by
Attachment: | Screen shot 2009-10-05 at 11.19.05 AM.png added |
---|
Scroll bars without padding issue (from revision [20078])
comment:18 Changed 11 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
I'm also seeing issues (still) with a tree inside an accordion pane as well. It doesn't get resized to the correct height.
comment:19 Changed 11 years ago by
Previously, the scroll bars would show up as part of the content pane...now, they show up as part of the child...which means that there is, by default, a 5px padding between the scroll bars and the content pane.
Hi, I agree that the padding is weird, but I think it's a larger issue. I think when there's a single (layout widget) child there shouldn't be any padding used... the ContentPane should be invisible, just a layer for deferring loading.
See for example test_TabContainer.html and compare the "Inlined SubTabContainer" tab to the "SubTabcontainer from href" tab. They look they same, as they should. That's currently implemented via a style="padding: 0" in the test file though, would be better to have it be the default when there's a single child.
I'm also seeing issues (still) with a tree inside an accordion pane as well. It doesn't get resized to the correct height.
Sounds like a serious problem... test case?
comment:21 Changed 11 years ago by
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
It's not an accordionpane...it's a custom widget that we were using...not a problem with this change.
comment:22 Changed 11 years ago by
(In [20532]) Only do the overflow: auto setting when Tree is functioning as a layout widget (ie, when resize(changeSize) (with a changeSize) has been called. Otherwise do the old overflow: visible.
I think this will be a less breaking change, particularly for the case where a narrow <div> contains a Tree widget, in that a horizontal scrollbar won't show up directly underneath the
comment:23 Changed 9 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
If dijit.form.Form is the only child of a ContentPane?, the contentPane has class "dijitContentPaneSingleChild", so it has no scrollbars. But there are neither no scrollbars in the form.
comment:24 Changed 9 years ago by
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
I don't understand what you are saying, "neither no" in the sentence above isn't proper english. But in any case, if you are having a problem you'll need to open a new ticket and attach a test case. All tickets need test cases.
happens in Chrome, too (V2.0 on Windows Vista)