#8309 closed defect (fixed)
Button: scrolling a button out of view and back distorts the button's text (IE7)
Reported by: | cswing | Owned by: | Douglas Hays |
---|---|---|---|
Priority: | high | Milestone: | 1.4 |
Component: | Dijit - Form | Version: | 1.2.3 |
Keywords: | ie7 button scrolling | Cc: | |
Blocked By: | Blocking: |
Description (last modified by )
Load the theme tester http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/themes/themeTester.html?theme=tundra
Resize IE7 so that the Enabled buttons can be scrolled out of view.
Scroll the buttons out of view and slowly scroll the buttons back into view. The buttons' text becomes distorted:
IE6 and FF3 did not display this behavior.
Attachments (9)
Change History (24)
comment:1 Changed 12 years ago by
Component: | General → Dijit |
---|---|
Description: | modified (diff) |
Owner: | anonymous deleted |
Summary: | IE7: Scrolling a button out of view and back distorts the button's text → Button: scrolling a button out of view and back distorts the button's text (IE7) |
Changed 12 years ago by
Attachment: | distorted.png added |
---|
comment:2 Changed 12 years ago by
I assume you are talking about the thing in the screen shot I just attached?
That's a weird one...
comment:3 Changed 12 years ago by
Yes, the picture is what I was describing. Interesting to note that the ComboBox? does not display the behavior.
comment:4 Changed 12 years ago by
Took a look at the theme tester and wanted to note that the problem no longer appears when using the browser's scroll bar, but is still present when using the inner scroll bar that is part of the tab pane (resizing of the window may be necessary).
comment:5 Changed 12 years ago by
Milestone: | tbd → 1.4 |
---|
comment:6 Changed 12 years ago by
Owner: | set to Douglas Hays |
---|
Doug, could this be fixed by your recent utility function to re-layout tables on scroll into view? Although, I guess a simple button isn't a table.
comment:7 Changed 12 years ago by
This fails with native buttons as well:
<button style="border:0px; overflow:visible;"> Native </button>
The combinaton of no border and overflow visible confuses IE7. With the Button widget, the button tag's parent has a border, not the button itself, and overflow:visible is necessary to prevent IE from adding button padding even when padding0 is specified.
Changed 12 years ago by
Attachment: | 8309.patch added |
---|
Move BUTTON tag to dijitButtonNode so border can be applied - needs careful review as the appearance of Button widgets is slightly altered with this patch
comment:8 Changed 12 years ago by
Thanks for tracing this down. The patch seems good to me. I took screenshots for the record. It looks like this now:
The patch introduces a white gap between the border and background on the bottom and left, but it's not too bad (and it's only on IE6/IE7, not on IE8 or other browsers). Maybe we could get rid of it w/a margin:-1px or something like that:
Without the patch, the other two options are (1) to add a border to the <button> node, but that introduces a white line in the middle of the button that looks quite bad:
And (2) the other option is taking away the overflow:visible but that does make the button quite a bit wider:
Changed 12 years ago by
Attachment: | current.png added |
---|
buttons with current template (until they are scrolled and get the chopped up look)
Changed 12 years ago by
Attachment: | noOverflow.png added |
---|
buttons w/out overflow:visible, that show up too wide on IE
Changed 12 years ago by
Attachment: | patched.png added |
---|
buttons w/Doug's patch to change markup, correct except for gap between border and background
Changed 12 years ago by
Attachment: | withBorder.png added |
---|
using existing template but adding a border to the buttons looks bad, even if it's color: transparent
Changed 12 years ago by
Attachment: | 8309.2.patch added |
---|
plan B: specify overflow:hidden on the BUTTON tag for IE7 and then remove auto-padding with computed width - needs careful review
comment:9 Changed 12 years ago by
Well the above patch fixes the problem, which is good. I confirmed that changing the browser text size works, in addition to changing the button label.
I tested performance on IE7 using dijit/bench/button.html (a markup test) and dijit/bench/create_widgets.html (a programmatic test). The first test showed the time increase from 1300 to 1700, which isn't so bad, although the second test showed the time increase from about 600 to 1800, which is troubling. (FYI I'm still showing IE7 at 45% market share.)
Changed 12 years ago by
Attachment: | activeBorderProblem.png added |
---|
problem with 8309.patch: when button is being depressed (mouse down), the border gets very dark/thick
comment:10 Changed 12 years ago by
comment:11 Changed 12 years ago by
One more issue with plan B (8309.2) patch: the disabled button in test_Button.html looks OK (on IE7), but the ones in themeTester.html don't. They are reduced to a very thin (essentially 0) width.
comment:12 Changed 12 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:13 Changed 11 years ago by
Unfortunately the above change apparently broke Buttons inside of TitlePanes (on IE7), see the Dojo Buttons inside TitlePane do not appear until after hover in Dojo1.4 thread on dojo-interest.
Developers with buttons inside of TitlePane's with this problem will need to add a custom rule:
.dj_ie7 .dijitButtonNode > BUTTON.dijitButtonContents > * { position:static !important; }
I guess we'll leave the code as-is for now, unless we come up with a better solution... not sure which problem is worse, the scrolling problem or the TitlePane problem. We'll see how many developers hit the TitlePane issue.
comment:14 Changed 11 years ago by
comment:15 Changed 10 years ago by
Component: | Dijit → Dijit - Form |
---|
screen shot