#4388 closed defect (fixed)
ComboBox down arrows "bleed through" overflow in IE
Reported by: | guest | Owned by: | Douglas Hays |
---|---|---|---|
Priority: | high | Milestone: | 1.1 |
Component: | Dijit - Form | Version: | 0.9 |
Keywords: | Cc: | [email protected]… | |
Blocked By: | Blocking: |
Description
We have an app that creates ComboBoxes? programmatically and adds them to dynamically created table cells. The table is contained within a div that has a defined height and overflow set to auto. In IE 6, the down arrows "bleed through" when they overflow the div. I'll attach a simplified example and screenshot. This works fine in FF 2.0.0.6 and I'm pretty sure it worked in IE 6 with 0.9 beta.
Attachments (4)
Change History (21)
Changed 15 years ago by
Attachment: | dojoCombo.html added |
---|
comment:1 Changed 15 years ago by
Milestone: | → 1.1 |
---|
comment:2 Changed 15 years ago by
Owner: | set to Sam Foster |
---|
comment:3 Changed 15 years ago by
Adding this to the test page seemed to make it work:
.dijitDownArrowButton { position: static !important; }
comment:4 Changed 15 years ago by
Here's a related forum thread. A comment from Karl suggested mentioning the timeframe we need the fix. Our app ships in February '08, so we'd really like to see this fixed in 1.0.
comment:5 Changed 15 years ago by
It's just that that position:static looks scary, like you'll scroll the page and the arrows won't scroll along with it.
comment:6 Changed 15 years ago by
I believe this is the culprit (from tundra.css):
.dj_ie6 .tundra .dijitButtonNode { position:relative; }
If you inspect a combo box with Firebug, you can see that the computed style includes static for position. Here's what the CSS 2.1 spec says about static:
The box is a normal box, laid out according to the normal flow.
comment:7 Changed 15 years ago by
Oops, I got confused between "static" and "fixed". But that "position:relative" is there for a reason (IIRC, to stop the bottom of the buttons getting cutoff). This doesn't make the problem recur?
comment:8 Changed 15 years ago by
I honestly don't know if using static causes other issues (I haven't noticed any), but now that I see the issue is related to dijitButtonNode, it means that other widgets will also demonstrate the "bleed through". I created a similar example using a bunch of NumberSpinner widgets. Is there a test case demonstrating the need for relative?
comment:9 Changed 15 years ago by
Changed 15 years ago by
Attachment: | buttonNode_4388_sfoster_20071015.patch added |
---|
(CLA) (PATCH) patch to tundra.css to give .dj_ie6 .tundra .dijitButtonNode zoom:1 instead of position:relative to trigger hasLayout
comment:10 Changed 15 years ago by
Status: | new → assigned |
---|
comment:11 Changed 15 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:12 Changed 15 years ago by
Milestone: | 1.1 → 1.0 |
---|
comment:13 Changed 15 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
This doesn't really seem to be fixed in 1.0.1. I'll attach another test page that displays problems with ComboBox?, NumberSpinner?, and ValidationTextBox? uner IE6. TextBox? seems to be handled properly. Obviously, I haven't tried every widget, but it's a bigger problem than just ComboBoxes?.
Changed 15 years ago by
Attachment: | dojoForm.html added |
---|
New test page that illustrates clipping issues with multiple widget types
comment:14 Changed 15 years ago by
Milestone: | 1.0 → 1.1 |
---|---|
Owner: | changed from Sam Foster to Douglas Hays |
Status: | reopened → new |
Passing to Doug. Sounds like something that needs to be fixed with the conversion from using <table> to just <div>'s with padding, so will have to wait to 1.1.
comment:15 Changed 15 years ago by
Status: | new → assigned |
---|
comment:16 Changed 15 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:17 Changed 11 years ago by
Component: | Dijit → Dijit - Form |
---|
Test case