Category: internet explorer

IE11 Select Box Bug Crashes Browser

On December 31, 2013

Try to set the selectbox size = 1 with an onchange event & this is what happens...

Try to set selectbox size = 1 with an onchange event with IE11 & this is what happens…

Woke up this morning to 20+ emails from people trying to use CarComplaints.com. When they clicked on select boxes on our forms, their browser crashed. It was only happening to Internet Explorer 11 users.

Usually as a web developer, I can’t crash browsers. That is, not unless I get special help from bad Microsoft code.

Didn’t take long to find the problem. By “problem”, I mean the perfectly valid Javascript code that causes IE11 to crash, instantly & every time.

We use select boxes with the “size” attribute set to show more than one choice. We have an “onchange” event that sets the select box size back to 1 when the user picks an option. That’s what caused IE11 to self destruct. It has worked great all the way back to the medieval days of the web.

Here’s a JSFiddle that demonstrates the problem. Doesn’t take much.

UPDATE: A possibly better workaround using onclick() is described at the end of this post.

A temporary workaround I found was to put the “selectbox.size = 1;” code into a setTimeout(….) with anything small for the timeout — I used 10ms:

setTimeout("selectbox.size = 1;",10);

Apparently we’re not the only ones that ran into this — The Cape Cod Times has a web page about what sounds to me like the same IE11 select box bug.

I posted a bug report on the IE dev site but then found this bug had already been reported, although the author used “combobox” in the title which isn’t really accurate.

Also looks like this isn’t the first IE11 select box bug …

UPDATE 1/1/14: A user responding to my post about this bug on the IE Dev forum pointed out that using the onclick event rather than onchange makes IE11 happy. The switch to .bind(‘click keyup’) worked great for our use case but may not be a universal fix for everyone.

IE6/IE7 form element margin inheritance bug

By Wick

On October 26, 2006

In bugs, internet explorer

Today I ran across an IE6/7 (and who knows, probably IE5 too) margin inheritance bug, involving block elements with IE’s hasLayout property triggered, that contain certain form elements. This bug appears to have very little online documentation or discussion (UPDATE: now documented by positioniseverything, see links section below).

IE margin inheritance bug

Any side margins (the blue 100px) applied to block-level hasLayout elements will be erroneously inherited (the red 100px) by text, submit, button and textarea fields contained within the block elements. Select boxes, checkboxes & radio buttons are not affected.

Applying margin: 0 to the input or textarea fields has no effect. All your margin are belong to us.

Here is my test page »

If your design does not have a border on the block-level element, this bug has the identical visual effect as the well-known IE6 floated element/margin-doubling bug, but the real cause is not the IE6 margin-doubling bug.

I found this issue having just installed IE7, still giddy over the wide array of css fixes. For a few minutes, I thought maybe the IE team had forgotten to fix the float/margin-doubling bug with blockified labels, but no.. this margin inheritance bug is an entirely different beast.

My findings are a little different from the other information I found (at the time of this post, the only existing explanation of this bug I could find was from Paul van Steenoven):

it does not matter if the elements are contained in a fieldset
input type=”checkbox” and type=”radio” are not affected

The fix / hack

wrap your bug-affected input / textarea elements in any inline element, like a span (if you’re okay with that .. I’m not)

Or, if possible:

set display: inline on the block-level hasLayout parent element, or similarly, remove the css property that’s triggering hasLayout (width, etc) on the block-level parent element (not possible in most cases)
remove side margins on all parent containers of the form element (suggested by Barry Jaspan, who points out this solution also may not be realistic)
set an IE-only negative margin on the affected form elements (also from Barry, who agrees with you this is needlessly messy, to the point where CSS purists may start throwing heavy objects)
include text on the same line just before the form element (yep, Barry again, nice catch. Not possible if you want the text above the form element.. for example, some text<br /> <input .. /> doesn’t work)
any others?

Other sites with information on this bug

Paul van Steenoven’s test page
the test page, expanded to show situations where Paul’s overflow: hidden fix does not work
quirksmode report

Update:

Barry Jaspan did a nice writeup, which was later covered by positioniseverything. I’m rather bitter, since I did my writeup about the bug about a month prior. Granted, Barry covered the issue more in-depth, and he also points out that the affected form elements actually inherit the sum of the side-margins of all parent elements, AND provided several more methods to work around the bug.

IE6/IE7 PNG gAMA bug makes PNGs appear darker

By Wick

On October 24, 2006

In bugs, graphics, internet explorer, tips

IE PNG gAMA bug
The link PNGs appear darker, except for Email A Friend, which has the gAMA chunk removed.

In setting up the new vehicle details page for DDC, I noticed that the background color for the 24-bit PNGs did not match the css background color, but only in IE6.

Searching online, I found this is a known bug with IE that stems from a flawed interpretation of the PNG’s gAMA setting. It’s fantastic that the IE team added PNG alpha transparency to IE7, but apparently they kept the gAMA bug in IE7 to make sure browser compatibility specialists keep their jobs for years to come.

In short, the fix is to remove the gAMA chunk using a tool such as TweakPNG or Pngcrush — I used TweakPNG (freeware, super easy to use, no installer) which worked great for fixing one image at a time. Fun stuff.