Dropdown arrow/caret not rendering properly in IE9

[trebiano]

I've noticed that the little arrow of dropdown menus in Bootstrap's navbar doesn't render properly in InternetExplorer 9 (Windows Vista)...

Have a look to the screenshot below:

from the official Bootstrap's example page:
http://getbootstrap.com/examples/theme/
http://getbootstrap.com/examples/sticky-footer-navbar/

Anyone experimenting the same weird thing ? Any way to adjust it ?

Thanks

[zacechola]

Potentially related to #16172.

[cvrebert]

I am unable to reproduce this on Sauce Labs, Win 7, IE 9:

[trebiano]

Thanks for your replies... don't know exactly what has changed in the meantime, but I've tried again this morning and the problem was disappeared :-)

[loicsimon]

I have the same problem with IE 11 but it depends on browser width. You can find a example with a width of 1280 pixels :

When I reduce the window to 1133 pixels, the problem disappears :

If I revert the fix for issue #15682 then the caret arrow isn't splitted anymore.

[cvrebert]

I can't reproduce on IE11:

@juthilo @XhmikosR Are either of you able to reproduce on IE11?

[patrickhlauke]

FWIW can't reproduce either (even tried setting monitor resolution to different sizes, and turning cleartype on/off) - [edit: i should add this was on Windows 8.1)

[XhmikosR]

Seems to work fine here too.

[loicsimon]

Maybe the problem occurs because I'm using IE11 through an RDP connection. I'll give it a try in two weeks (i'm currently on vacation).

[patrickhlauke]

That could indeed be part of the issue ... I've seen some similar problems before with screen resolutions that aren't completely matching native screens, and some browsers then simply dropping a 1px line or mysteriously reintroducing a 1px gap somewhere)

[architshukla]

I was having the same issue today on IE. Explicitly setting a height of 5px on the span seemed to fix the issue.

<span style="height: 5px;" class="caret"></span>

Works fine on Firefox before and after doing this.

Before

After

[XhmikosR]

I wonder if that has any side effects. If not, it seems like a good
solution.
On May 12, 2015 11:16 PM, "Archit Shukla" notifications@github.com wrote:

I was having the same issue today on IE. Explicitly setting a height of
5px on the span seemed to fix the issue.

Works fine on Firefox before and after doing this.

Before
[image: before]
https://cloud.githubusercontent.com/assets/4814585/7597434/1cbb1338-f911-11e4-8bfe-8e198a054264.png

After
[image: after]
https://cloud.githubusercontent.com/assets/4814585/7597441/22fe896e-f911-11e4-9df9-cd08d406d1ab.png

—
Reply to this email directly or view it on GitHub
#16203 (comment).

[XhmikosR]

I mean we set height: 0 for caret; there must be some reason for this.
On May 12, 2015 11:28 PM, "XhmikosR" xhmikosr@gmail.com wrote:

I wonder if that has any side effects. If not, it seems like a good
solution.
On May 12, 2015 11:16 PM, "Archit Shukla" notifications@github.com
wrote:

I was having the same issue today on IE. Explicitly setting a height of
5px on the span seemed to fix the issue.

Works fine on Firefox before and after doing this.

Before
[image: before]
https://cloud.githubusercontent.com/assets/4814585/7597434/1cbb1338-f911-11e4-8bfe-8e198a054264.png

After
[image: after]
https://cloud.githubusercontent.com/assets/4814585/7597441/22fe896e-f911-11e4-9df9-cd08d406d1ab.png

—
Reply to this email directly or view it on GitHub
#16203 (comment).

[architshukla]

The problem recurred today. For page zoom % set at 100% is looks fine but it starts rendering incorrectly at 105%. I did, however, notice that the CSS class for caret had a dashed border top.

.caret {
    ...
    border-top: 4px dashed;
    ...
}

Changing it to a solid border fixed the issue for me today and I reset the height to 0px. Although, it's weird that this happened only on IE. The caret looks fine on Firefox and Chrome before and after I made the change.

.caret {
    ...
    border-top: 4px solid;
    ...
}

Was there a reason to use a dashed background for creating the triangle and do you see and side effects that could stem from this?

[XhmikosR]

@mdo @cvrebert: this seems to be a rather new change in 119ce26

Also, as you can see in that commit, there are more reports there.

I say we revert that change.

[cvrebert]

@XhmikosR I think we fixed that in #16258. Page zooming is a lost cause.

[XhmikosR]

If that PR fixed the issue, then I agree about zooming, it isn't important
at this point.
On May 16, 2015 9:01 PM, "Chris Rebert" notifications@github.com wrote:

@XhmikosR https://github.com/XhmikosR I think we fixed this in #16258
#16258. Page zooming is a lost
cause.

—
Reply to this email directly or view it on GitHub
#16203 (comment).