Fixed bugs in IE8

Fixed bugs in IE8:

We've started to aggressively mark those bugs that are fixed in IE8 as such. The final version of IE8 has yet to be released but there is a presumption that a bug that is fixed in IE8 RC1 will remain fixed for the IE8 RTM release.

However there is a significant catch. When Microsoft fixed most of these bugs, they only fixed them in the "IE8 Standards Mode" which is the new mode that IE renders content in its "best possible, most standards way that it can".

This means that in order to see any of these fixes work, you MUST generate your pages with a valid doctype and the page MUST be somewhere on the Internet, not the Intranet (A point most developers argued against but Microsoft stood firm).

That all said, bugs marked with the "Fixed" tag are bugs that from preliminary testing appear to be working fine in IE8 in IE8 Standards Mode.

With deep regret (ours) there are also bugs that Microsoft has indicated will not be fixed in IE8 RTM, and those have been marked with the "Broken By Design" tag.

IE8 RTM is on the horizon now and the IE Team has indicated that there will not be any more public IE releases before the final (we hope that means there will be another private release, but we aren't getting our hopes up).

If/When time permits, we'll publish a complete list right here so that there is a quick list to check against. Thanks for all the input and bug submissions (for any browser of course) and feedback.

[List will go here]
Fixed:
(bug 101) - buttons render stretched and distorted in IE (WinXP)

(bug 152) - getElementById returns incorrect objects in IE and Opera

(bug 154) - getElementById is NOT case sensitive in IE

(bug 163) - no valign in table cells in IE8

(bug 165) - dynamic pre population fails in IE

(bug 184) - The catch to Try Catch Finally in IE

(bug 190) - fieldsets are broken in IE8

(bug 215) - no hasAttributes() support in IE6, IE7

(bug 217) - getAttribute doesn't always work in IE

(bug 229) - not everything is absolute in IE

(bug 268) - hasAttributes not supported in IE

(bug 293) - can't disable options in IE

(bug 299) - setAttribute "checked" does not work in IE

(bug 329) - Element.setAttribute('style', '...') fails in IE8 Beta 1

(bug 333) - microsoft drops all support for opacity in IE8!

(bug 341) - the button element submits the wrong value in IE

(bug 347) - IE8 Beta 1 - text highlighting background issue

(bug 371) - named anchor links are broken in IE8

(bug 471) - font-weight:600 stretches text in IE



Broken By Design:
Status: Microsoft has confirmed that these bugs will NOT be fixed in IE8 RTM
(bug 109) - JavaScript prompt() in IE - How did this not get fixed in IE7?!

(bug 126) - no W3C DOM Level 2 Event Listeners

(bug 132) - slow checking checkboxes required in IE

(bug 210) - No .innerHTML support on Table, THead, TBody, TFoot, Tr's in IE

(bug 237) - type is a readonly attribute in IE

(bug 256) - DOM nodeType constants are not in IE and Opera

(bug 274) - DOM Methods on Select Lists don't work in IE

(bug 342) - Connecting... in IE7 / IE8 takes F-O-R-E-V-E-R

(bug 411) - getElementsByName doesn't work in IE

(bug 421) - IE fails to pass the HTTP Referer on many navigations

Bug/Site Feedback |
Submit a bug

bug 471 - font-weight:600 stretches text in IE

Issue: #471
Affects: IE6, IE7, IE8 Beta 1, IE8 Beta 2, Chrome 5,6,7
Fixed In: IE8 PR 1

Update: This apparently affects Google Chrome now (v5,6,7)


When styling text on your site there are several options for bolding. You can use the classic <b> tag, the <strong> tag, or any tag with styling set for the font-weight.

Example:

<style type="text/css">
  .example1{
    font-weight:bold;
  }
  .example2{
    font-weight:700;
  }
  .example3{
    font-weight:??;
    /*normal|bold|bolder|lighter|100|200|300|400|500|600|700|800|900|inherit*/
  }
</style>

Every option works as intended with the exception of 600 in IE. IE will render any text with a font-weight:600 about 10% wider than normal text (regardless if ClearType is turned on or off).

The Quick Brown Fox Jumps Over The Lazy Dog. Please Don't Hurt The Web - Use Web Standards. (@500)

The Quick Brown Fox Jumps Over The Lazy Dog. Please Don't Hurt The Web - Use Web Standards. (@600)

The Quick Brown Fox Jumps Over The Lazy Dog. Please Don't Hurt The Web - Use Web Standards. (@700)

Note: Updated the style to a fixed-width font to better illustrate.

Known Workarounds: None.

Related Issues: None.


Bug/Site Feedback |
Submit a bug

bug 215 - no hasAttributes() support in IE6, IE7

Issue: #215
Affects: IE6, IE7
Fixed In: IE8 Beta 2

The hasAttributes() method is available on the Node element in DOM 2 (W3C).

Test:

Known Workarounds: One. Test using a try/catch for the specific attribute you care about.

Related Issues: None.


Bug/Site Feedback |
Submit a bug

bug 190 - fieldsets are broken in IE8

Issue: #190
Affects: IE8 Beta 1
Fixed in: IE8 Beta 2
MSIE Feedback ID: 336258
An anonymous poster has indicated that this is fixed in "Internal" builds shared with 3rd parties. Am I the only one that would love to be in on this "special list"? ;-) That said, glad to hear a fix is apparently on the way.

A Fieldset is really simple, you have a wrapper, and a legend which graphically wrap 1 or more form fields.

Communication preferences:

Please use the following methods to contact me;
Email
ICQ
MSN Messenger
Yahoo! Messenger
Google Talk
Phone
Fax
Skype

As you can see, (if you use IE8) the legend does not render correctly at all. Hopefully this is just a bug in this first Beta. Stay tuned for updates as further beta releases become available.

Known Workarounds: None.

Related Issues: None.

Bug/Site Feedback |
Submit a bug

bug 119 - no title for options or select in IE6

Issue: #119
Affects: IE6
Fixed In: IE7

Note: Updated synopsis to include the select element, not just the options.

Have you ever wanted to provide more descriptive text in the form of a tooltip in your Web applications? Of course you have. It may have slipped your notice though, that this doesn't work on select list options (or even the select list itself) in IE6 (fixed in IE7).

Example:

<select size="3">
  <option value="1" title="Web Bug Track">WBT</option>
  <option value="2" title="Bugzilla Bug Tracking">Bugzilla</option>
  <option value="3" title="Tracker Bug Track">Tracker</option>
</select>

WBT
Bugzilla
Tracker

Known Workarounds: None.

Related Issues: (bug 291) (bug 280).

Bug/Site Feedback |
Submit a bug

bug 163 - no valign in table cells in IE8

Issue: #163
Affects: IE8 Beta 1
Fixed in: IE8 Beta 2
MSIE Feedback ID: 333908


A regression bug has been found in IE8 (Beta 1) whereby it is impossible to set the valign attribute of a TD or TH cell.

No matter what you try to set this to: valign="top", valign="middle", valign="bottom" it will always set it to behave as "bottom".

Example:

top	middle	bottom
top	middle	bottom

Known Workarounds: None.

Related Issues: None.

Bug/Site Feedback |
Submit a bug

bug 403 - another getElementsByName() bugs in IE

Issue: #403
Affects: IE6, IE7
Fixed in: IE8 Beta 2


Related to (bug 411), another bug with getElementsByName( name ); has been noted.

If you dynamically change the name attribute of an element (e.g. an input box) it will affect the form submission, but in IE it won't actually change the name attribute. See these bugs: (bug 199), (bug 235), (bug 237), (bug 240) & (bug 242)

What this also means, is that in IE, if you try to retrieve the elements you have renamed, you will not be able to retrieve them.

Example:

<script type="text/javascript">
  var myElem = document.forms[0].elements['oldname'];
  myElem.name = 'newname';//can't use .setAttribute() due to another IE bug
  
  //how many elements with the name 'newname' do we now have?
  alert(document.getElementsByName('newname').length + ' elements found!');
</script>

In IE, this will alert ZERO.

Known Workarounds: None.

Related Issues: None.

Bug/Site Feedback |
Submit a bug

bug 371 - named anchor links are broken in IE8

Issue: #371
Affects: IE8 Beta 1, IE8 Beta 2
Fixed In: IE8 PR 1


MSIE Feedback ID: 331609

A regression bug has been found in IE8 Beta 1 whereby an anchor link will not work if the anchor doesn't contain a text node.

Example:

<a name="broken"/>

<a name="works">This works</a>

Known Workarounds: None.

Related Issues: None.

Bug/Site Feedback |
Submit a bug

bug 333 - microsoft drops all support for opacity in IE8!

Issue: #333
Affects: IE8 Beta 1 - IE8 RTM?
Status Fixed in IE8 PR1 (see notes)
MSIE Feedback ID: 331735

According to blogs around the 'Net and the IE Feedback site Microsoft has dropped all support for CSS opacity in IE8.

This includes the CSS3 property:

opacity: 0.25;
AND
filter:alpha(opacity=25);

Apparently this is "By Design". As a developer I seriously hope they reconsider this. The filter hack wasn't the best, but no method to set opacity is certainly not "innovation".


Example:

<style type="text/css">
.inDragMode {
  opacity: 0.25;
  filter: alpha(opacity=0.25);/* Hack for IE 6-7? */
}
</script>

Known Workarounds: Fixed (Notes): One.
As part of IE8's push towards better supporting Web standards they needed to alter the syntax of the proprietary filter() syntax. To make opacity work in IE8 (and all browsers), you'll need to do this.

#faded {
  opacity: .5; /* Standards Based Browsers */
  filter: progid:DXImageTransform.Microsoft.Alpha(Opacity=50); /* IE (before IE8) */
  -ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=50)"; /* IE8 */
}

or for the short form:

#faded {
  opacity: .5; /* Standards Based Browsers */
  filter: alpha(opacity=50); /* IE (before IE8) */
  -ms-filter: "alpha(opacity=50)"; /* IE8 */
}

Related Issues: None.

Bug/Site Feedback |
Submit a bug

bug 347 - IE8 Beta 1 - text highlighting background issue

Issue: #347
Affects: IE8 Beta 1
Fixed: IE8 Beta 2

In IE8 Standards Mode, if you have a block element (e.g. a div) with a background image applied, when the user selects text within the block, the background image is re-applied to the selection with a new offset matching the top left of the selection.

Known Workarounds: None.

Related Issues: None.

Bug/Site Feedback |
Submit a bug

bug 329 - Element.setAttribute('style', '...') fails in IE8 Beta 1

Issue: #329
Affects: IE8 Beta 1
Also Affects: IE6, IE7
Fixed In: IE8 RC1

The setAttribute() method was reported fixed in IE8 (whitepaper Pg.5), however some tests have indicated otherwise.

In particular, attempting to set the 'style' attribute on an element in IE8 Beta 1 still fails as it did in IE6, & IE7.

Please note that for any IE8 related bugs, all tests are done in "IE8 Standards Mode".

Example:

<script type="text/javascript">
  var obj = document.getElementById('myObj');
  //the following call will fail in IE8 Beta 1
  obj.setAttribute('style','border:2px solid #ff0000;color:#00ff00;');
</script>

Known Workarounds: One. Although you can set: obj.style.setAttribute('cssText','...'); as outlined in (bug 245) IE8 was supposed to fix this, thus this is not an ideal workaround.

Related Issues: (bug 245), (bug 242).

Bug/Site Feedback |
Submit a bug

bug 165 - dynamic pre population fails in IE

Issue: #165
Affects: IE6, IE7, IE8
Fixed in: IE9 PP4

The <pre> tag is the one tag that will allow you to put pre-formatted content on the screen. It's the only way to display code or structured text without losing all the whitespace markup.

What's odd, is that you can't set the contents in IE using .innerHTML because if you do, you will lose all of your whitespace formatting.

Example:

<script type="text/javascript">
 myPreObj.innerHTML = 'This\nWill\nFail...     no linebreaks or spaces';
</script>

Known Workarounds: One. Setting the .innerHTML to well the .innerHTML magically fixes this issue (and some others in an upcoming article).

Example Workaround Code:

<script type="text/javascript">
 myPreObj.innerHTML = 'This\nWill\nFail...     no linebreaks or spaces';
 myPreObj.innerHTML = myPreObj.innerHTML;
</script>

That's right! "Set my inner content, to my inner content" - fixes this bug in IE... go figure?

Related Issues: One. It has come to our attention that trying to append a text node to the pre element via appendChild() will fail to handle whitespace properly and the hack above to set the innerHTML to itself will not fix it.

Bug/Site Feedback |
Submit a bug

bug 114 - border dashing and rounding not an option in Firefox

Issue: #114
Affects: Firefox 2.x
Fixed in: Firefox 3 (Beta 3 & Final)

Rounded corners make simple boxes look so much more appealing on the Web. CSS3 defines the border-radius CSS property, but of course Firefox, Safari and others implemented their own versions long ago before CSS3 was finalized.

In Firefox, specifying "-moz-border-radius: 5px;" for a block element will give a nice gentle curved corner to any box.

However, if your border is more than 1 (one) pixel in width, and you have it set to dashed, or dotted (e.g. not solid), then Firefox will not show the dashed/dotted pattern, but instead show a solid line.

The good news is that Firefox 3 (currently in Beta) appears to have fixed this issue.

Example:

<style type="text/css">
  div.fancy {
    border: 2px dashed #000066;
    -moz-border-radius: 5px;
  }
</style>
<div class="fancy">
This box should have a:<br/> dark blue<br/> 2 pixel<br/> dashed border<br/> with 5 pixel radius<br/> rounded corners.
</div>

This box should have a:
dark blue
2 pixel
dashed border
with 5 pixel radius
rounded corners.

Known Workarounds: None.

Related Issues: None.

Bug/Site Feedback |
Submit a bug

bug 229 - not everything is absolute in IE

Issue: #229
Affects: IE6, IE7
Fixed in: IE8 Beta 1

The css "position:absolute" property works well to position a block element in an exact location on screen. However reader Xogede pointed out to us that there are scenarios where IE displays the element correctly, but it doesn't fire events on the element unless the event was triggered on the "text" portion inside the element.

To see this in action, save the code below and open it up in IE6 or IE7. If you click on the text, the onclick event fires and you'll see an alert. If you click anywhere else inside the DIV no event will fire. I've set the cursor to "pointer" so that you can see exactly where the event will fire, but it will turn to the default arrow anywhere that the event firing will fail. Load it up in any other browser and you can click anywhere in the DIV to fire the event.

Example:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
  <title>bug 229 - not everything is absolute in IE</title>
</head>
<body>
<div style="position:absolute;cursor:pointer;top:10px;left:10px;width:200px;border:1px solid black;height:50px;" onclick="alert('Clicked!')">Absolute</div>
</body>
</html>

What is truly odd about this bug, is that it happens in Standards Mode (you know, the one that is supposed to be "closest" to the specs).

The good news is, that this bug can be fixed. All you need to do is specify a background color, e.g. just add this to the DIV's style attribute:
"background-color:#ffffff;"

Known Workarounds: One. Set a background color.

Example Workaround Code:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
  <title>bug 229 - not everything is absolute in IE</title>
</head>
<body>
<div style="position:absolute;cursor:pointer;top:10px;left:10px;width:200px;border:1px solid black;height:50px;background-color:#fffedf;" onclick="alert('Clicked!')">Absolute</div>
</body>
</html>

Related Issues: None.


Bug/Site Feedback |
Submit a bug

bug 111 - IE Broke The Web 2.0

Issue: #101
Affects: IE5, IE5.5, IE6
Trackers:
MSKB Tracker: 177378
Fixed in: IE7

The most significant part of Web 2.0, was the ability to put more relevant content on the screen for a user. It could be a Gmail popup with a users' avatar, or a DHTML inline popup calendar, an AJAX based "lightbox", or the coolest form widgets we've ever seen, etc.

Almost any "Web 2.0" site/application uses some level of floating elements... but unless you only support IE >= 7, doing this requires an intimate knowledge of IE's worst rendering bug ever.

No matter what CSS z-index you set, you can't float an element (like a div) over a select list!

Example:

<style type="text/css">
#item_1 {
  left: 75px;
  position: absolute;
  top: 75px;
  z-index: 0;
}
#item_2 {
  background-color: #efefef;
  border: 1px solid #0000ff;
  display: block;
  height: 200px;
  left: 100px;
  position: absolute;
  top: 100px;
  width: 300px;
  z-index: 9999;
}
#item_3 {
  left: 150px;
  position: absolute;
  top: 150px;
  z-index: 10;
}
</style>
<select id="item_1">
<option value="4">Always Renders Through!</option>
</select>
<div id="item_2">This should float over anything!</div>
<select id="item_3">
<option value="7">Always Renders Through!</option>
</select>

Always Renders Through!

This should float over anything!

Always Renders Through!

Known Workarounds: Three ugly hacks.
1.) Hope that a select will never appear under your floating elements. (a.k.a. Ostrich with head in the sand technique)
2.) Hide select lists, whenever showing a floating element (very quirky behavior for the end user)
3.) Float an iframe (with nothing in it) over the area first, then float the element

Option 1 only works if you can 100% guarantee that nothing will overlap your select lists (e.g. not likely). Option 2 works, but looks horrible, thus leaving Option 3 as the only reasonable workaround... and yes, it requires the most work of the 3 options.

Example Workaround Code:

<coming soon...>

Related Issues: None.

bug 293 - can't disable options in IE

Issue: #293
Affects: IE5, IE5.5, IE6, IE7, IE8, IE9 PP4
Partially Fixed in: IE8 Partner Release 1

MSIE Feedback ID: 336685

Yet another issue with select lists in IE. First you couldn't style them (bug 291) then it turns out, you can't disable them either!

Example:

<select>
  <option>I am valid</option>
  <option>I am valid too</option>
  <option disabled="disabled">I am NOT valid</option>
  <option>I am also valid</option>
</select>

Try it for yourself, load this page up in IE and any other browser.

I am valid
I am valid too
I am NOT valid
I am also valid


Update: IE8 partially fixed this in that you can disable options and thus they render grayed out and can't be selected by mouse - however they can still be selected by alphabetic key presses. (e.g. in the sample above, press "i" until you see that you've selected the disabled option)

Known Workarounds: None.

Related Issues: bug 291.

bug 299 - setAttribute "checked" does not work in IE

Issue: #299
Affects: IE5, IE5.5, IE6, IE7
Fixed In: IE8 RC1

If you use the DOM Methods to build up new content for your page, be aware that in IE, you can't pre-check a radio button or a checkbox using .setAttribute('checked', 'checked'); or even myCheckBoxObject.checked = true; *unless* you add the element to the page first.

Example:

<script type="text/javascript">
  var cb1 = document.createElement('input');
  cb1.setAttribute('checked', 'checked');
  document.getElementsByTagName('body')[0].appendChild( cb1 );
</script>

In all other browsers, this would add the checkbox to the page, pre-checked.

Known Workarounds: Two. You can set the checked attribute after you've appended your element to the DOM (so it will flash momentarily before being checked), or, you can call cbObj.setAttribute('defaultChecked', 'defaultChecked'); which will also work.

Note, when setting the checked, or the defaultChecked attribute, any value for "true" will work.

Example Workaround Code:

<script type="text/javascript">
  var cb1 = document.createElement('input');
  cb1.setAttribute('defaultChecked', 'defaultChecked');
  document.getElementsByTagName('body')[0].appendChild( cb1 );
</script>

Related Issues: bug 235, bug 237, bug 242.

bug 287 - can't float over an iframe in Konqueror

Issue: #287
Affects: Konqueror 3.5.4
Status: [Fixed!]
Fixed in: Konqueror 4.0

Advanced web sites and applications these days tend to "float" content above the document window to provide dynamic tooltips, calendars, option lists, lightbox effects for image galleries etc.

In order to be able to do this, an element must be "floated" above the rest of the page, often with a higher z-index value to ensure it stays above all other elements.

In Konqueror however, you can't float elements above an iframe, regardless what the z-index is set to. The only exception is that you can float another iframe, over an iframe. See KDE Bug ID:141615.

Example:

<style>
#myFloaterDiv {
  position: absolute;
  width: 200px;
  height: 200px;
  top: 100px;
  left: 100px;
  z-index: 1000;
}
#myIframe {
  position: absolute;
  width: 300px;
  height: 300px;
  top: 200px;
  left: 200px;
}
</style>
<div id="myFloaterDiv">
  Floating above
This should be above the iframe.
</div>
<iframe id="myIframe" src="http://www.digg.com/">
</iframe>

Known Workarounds: None.

Related Issues: None.

bug 184 - The catch to Try Catch Finally in IE

Issue: #184
Affects: IE5, IE5.5, IE6, IE7
Fixed In: IE8 RC1


Like several programming languages, JavaScript offers the try/catch/finally block. This allows for errors to be handled gracefully, rather than halting the page execution.

You place code that might cause an error in the try section. If an error occurs, the catch section will allow you to handle it, and the finally block is always executed regardless if an error occurred or not.

The finally part is optional, as is the catch part. (wikipedia reference)

However, in IE, if you don't supply a catch statement, your finally statement will never be called!

Example:

<script type="text/javascript">
  //this works
  try {
    window.undefinedMethod();
  } catch(e){
    alert('Error: ' + e);
  } finally {
    alert('about to print...');
    window.print();
  }

  //this fails in IE
  try {
    window.undefinedMethod();
  } finally {
    alert('about to print...' +
      '\nBut IE will never show this message' +
      '\nNor will it call print()');
    window.print();
  }
</script>

Known Workarounds: One. Although the catch is supposed to be optional, to make IE work properly include an empty catch.

Example Workaround Code:

<script type="text/javascript">
  try {
    window.undefinedMethod();
  } catch(e){
    //ensure IE executes the finally section
  } finally {
    alert('about to print...' +
      '\nIE will show this message' +
      '\nand it will call print()');
    window.print();
  }
</script>

Related Issues: None.

bug 341 - the button element submits the wrong value in IE

Issue: #341
Affects: IE5, IE5.5, IE6, IE7
Fixed in: IE8 Beta 1

The button element in HTML, just like an input element (of type button) is designed (by spec) to submit the contents of the value attribute when it is pressed to submit a form. However in Internet Explorer, this functionality is broken as it submits the innerHTML of the button element rather than the contents of the value attribute.

Example:

<button value="true_content" name="doAction">
  <span style="font-weight:bold;">Please</span> click <em>Me</em>!
</button>

If a user clicked this button, the server should get a parameter called "doAction" with a value of "true_content". IE on the other hand, will return the same parameter, with the value ' <span style="font-weight:bold;">Please</span> click <em>Me</em>!'.

Known Workarounds: None. See MSDN for the latest news on when the button element will be fixed.

Related Issues: bug 101.