bug 190 - fieldsets are broken in IE8

Issue: #190
Affects: IE8 Beta 1
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 249 - you can't press Tab in IE and capture it

Issue: #249
Affects: IE6, IE7, IE8 Beta 1

Believe it or not, you can't capture the keypress event for the Tab key in IE (any version).

Are you serious? I hear you ask... well, lets make proving this fun.

In the following textarea, type in any key... you'll get $5* for any key, but you'll get $2,500* for pressing the Tab key.

Example:

Winnings!
$

You can make a boatload of cash in Firefox, Safari, Opera and Konqueror but you'll never get a $2,500 payout in IE.

Known Workarounds: None. If you want to capture the Tab key, you'll need to capture the keydown and keyup events instead.

*All currency is of the imaginary non-legal currency type.

Related Issues: None.


Bug/Site Feedback |
Submit a bug

bug 149 - no DOM Level 2 Mutation Events in IE

Issue: #149
Affects: IE6, IE7, IE8 Beta 1

The W3C specs for (W3C DOM2 Mutation Events) (Nov 2000) specify events that allow developers to listen for changes in the DOM, so that they can apply JavaScript on-demand, as needed.

In particular, noting when a DOM element has children added or changed are the key moments developers would like to be able to apply a sprinkle of JS.

Being able to use these events would be fantastic, but support for them in IE is non-existent at the moment.

Known Workarounds: None.

Related Issues: None.


Bug/Site Feedback |
Submit a bug

bug 140 - changing mailto: links error in IE

Issue: #140
Affects: IE6, IE7, IE8 Beta 1

If you've ever wanted to set the href attribute of a link (a element) to a URL that uses the mailto: protocol, beware...

In IE, if you set this href attribute to "mailto:name@example.com" or any other string that contains the "mailto:" protocol and the @ symbol, IE will overwrite the content of the a element.

Example:

<a id="contactLink" href="http://www.example.com/about.html">
Send us your thoughts!
</a>
<script type="text/javascript">
   var cL = document.getElementById('contactLink');

   //this fails in IE
   cL.href = 'mailto:info@example.com?subject=My%20Thoughts';

   //this also fails in IE
   cL.setAttribute('href','mailto:info@example.com?subject=My%20Thoughts');
</script>

Using the code above, would transform the link from this:
Send us your thoughts!
to this:
mailto:info@example.com?subject=My%20Thoughts

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
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 417 - isNaN() might return false when you expected true

Issue: #417
Affects: All Browsers

The JavaScript isNaN(testValue) function will return true if the testValue is Not A Number. Likewise a false return value would signify that the testValue was actually a number.

isNaN('foo');//true
isNaN(37);//false
isNaN('123456789w');//true
isNaN('12345e6789');//false

Huh?! What?! but there is a letter in there!

Since Scientific notation allows the letter 'e' to be used to indicate very, very small and very, very big numbers ("e" represents "times ten raised to the power"), one can only guess that the parsing allows all digits, zero or one decimal, AND zero or one 'e' character...

Tuck that one in your JavaScript toolbelt for a rainy day. ;-)

Known Workarounds: One. If this truly worries you when reading in a value, you can run an additional test against the string...

Example Workaround Code:

  var testStr = '12345e6789';
  var isNumber = !isNaN(testStr);
  if(isNumber){
    if(testStr.indexOf('e') != -1){
      isNumber = false;
    }
  }
  alert('The test value is a number?: ' + isNumber);

Keep in mind, that '123e14' is a valid number, just likely not what your application is expecting in terms of the size of the number. ;-)

Related Issues: None.

Bug/Site Feedback |
Submit a bug

bug 255 - animated GIF image rendering issues in IE

Issue: #255
Affects: IE6, IE7, IE8

In general IE has no issues rendering Animated GIF images... however with all this Web 2.0 stuff going on where animated "spinners" are used to indicate "activity" in AJAX applications a bug has started to become exposed.



It is common to have a pre-loaded animated GIF image rendered as part of a page, that has its style (or a wrapping element) set to display:none;

Then whenever it is needed, simply setting the display to 'inline','block' or even '' will then display the animated image.

The problem is, that sometimes IE refuses to animate the image. It just sits there in a still frame as if there were no animation sequence.

It appears to be some sort of threading/race condition and is most obvious if right after setting the display back to a "visible" state the location.href is changed, or the form is submitted.

Its one of those odd bugs that doesn't always happen, but appears "glitchy" when it does.

Example:

<img src="img/busy.gif" width="16" height="16" border="0" style="display:none;"/>
<script type="text/javascript">
  var busy = document.getElementById('busyicon');
  busy.style.display = 'inline';//or try '', or 'block'
  document.forms[0].submit();
</script>

Known Workarounds: Some kind of sorta? There are various speculations on this (and I'm opening comments on this to bring in more), but anything that attempts to reload the src of the animation afterwards, or in another thread appears to help.

Example Workaround Code:

<script type="text/javascript">
  //spawn another thread to show activity
  setTimeout('showSpinner',150);//spawns another thread to kick off after the submit
  document.forms[0].submit();

  function showSpinner(){
    var busy = document.getElementById('busyicon');
    busy.style.display = 'inline';//or try '', or 'block'
  }
</script>

Related Issues: None.

Bug/Site Feedback |
Submit a bug

bug 289 - popup window name can't have spaces in IE

Issue: #289
Affects: IE6, IE7, IE8 Beta 1

When you open a popup window in your web applications using the JavaScript window.open() function if you must specify the name of the window, it mustn't contain spaces in IE, or the function will fail to open the window.

Example:

<script type="text/javascript">
  var url = 'http://www.google.com/q?Hello=World';
  var featureList = 'width=500,height=400';
  var childWin = window.open(url, 'name of child win', featureList);
</script>

Known Workarounds: One. Quite simple. Be sure that all your popup window names do not contain spaces.

Example Workaround Code:

<script type="text/javascript">
  var url = 'http://www.google.com/q?Hello=World';
  var featureList = 'width=500,height=400';
  var childWin = window.open(url, 'name_of_child_win', featureList);
</script>

Related Issues: None.

Bug/Site Feedback |
Submit a bug

bug 122 - in IE an HTTP 204 status may magically become a 1223 status

Issue: #122
Affects: IE6, IE7, IE8?

If you send an XMLHttpRequest that only returns headers (e.g. no content), and you are looking for a 200 status, you'll end up getting a 204 status. In itself that's just fine, but in IE that status might become a 1223 status instead!

Known Workarounds: None. Adjust your response tests as needed to handle this additional IE status.

Related Issues: None.

Bug/Site Feedback |
Submit a bug

bug 326 - field names in IE that break with Mootools

Issue: #326
Affects: IE6, IE7, IE8 Beta 1?
JS Library: Mootools
Mootools Trac#:798

The following fields (name or id) will cause issues in Mootools:

"addEvent", "match", "position", "search"

Due to conflicts when the name exists in Element.Prototype, it will cause issues.

Example:
These will fail when you try to iterate using .each (for example) over a form element array.

<input id="addEvent"/>
<input id="match"/>
<input id="position"/>
<input id="search"/>

<input name="addEvent"/>
<input name="match"/>
<input name="position"/>
<input name="search"/>

Known Workarounds: None. (other than to be careful not to use these field identifiers)

Related Issues: None.

Bug/Site Feedback |
Submit a bug

where are all the IE CSS bugs?

Issue: #450-???
Affects: IE6, IE7, IE8 Beta 1(some)

I received an emai1 {ThisSiteTitleWithNoSpaces@gmail.com} from Nelson T. recently asking where all the IE CSS bugs are? There are several of them, many even have their own name! However it makes much more sense for me to provide a link to better documentation and examples rather than try to re-invent the wheel.

I do have some CSS bugs to report that (I don't believe) are listed elsewhere though, and thus I plan to post those very shortly.

IE CSS Bugs:

The following collection is all available at:
Position Is Everything (PIE), complete with test cases and workarounds (where possible)

• Peekaboo Bug


• Inherited Margins on Form Elements


• Expanding Box Problem


• Quirky Percentages in IE Visual Formatting Model


• IE Line Height Bug


• Border Chaos


• Disapearing List Background Bug


• Guillotine Bug


• Unscrollable Content Bug


• Duplicate Characters Bug


• IE Italics Bug


• Double Float Margin Bug


• Duplicate Indent Bug


• 3 Pixel Text Jog Bug


• Escaping Floats Bug


• Creeping Text Bug


• Missing First Letter Bug


• Phantom Box Bug

Bug/Site Feedback |
Submit a bug

bug 253 - more Array issues in IE

Issue: #253
Affects: IE6, IE7, IE8 Beta 1

This is more of a minor issue, but its just one more thing you'll need to watch out for.

Example:

<script type="text/javascript">
  var foo = ['a','b','c','x','y','z',];
  alert(foo.length);
</script>

What would you expect in the alert? 6? Well yes, but not in IE. IE will add a 7th element to the array, which is "undefined".

Think about that for a moment. If the so-called 7th element is "undefined", then why is it there? IE just told us that it is not defined!

Known Workarounds: One. Just be sure that all your Array definitions are "clean" especially if they are generated with some server side code.

Example Workaround Code:

<script type="text/javascript">
  var foo = ['a','b','c','x','y','z'];
  alert(foo.length);
</script>

Related Issues: (bug 230), (bug 181).

Bug/Site Feedback |
Submit a bug

bug 230 - no Element.attributes array in IE8

Issue: #230
Affects: IE8 Beta 1

When inspecting an element (especially in IE) we often look to the attributes array to get information on what is set.

There are actually 4 ways to get access to an attribute using the attribute array.

1.) Iterate over each index in the array
2.) Iterate over each key in the array (associatively)
3.) Get by index
4.) Get by key

Unfortunately in IE8 Beta 1, all of the above are broken!

Example:

Test DIV
with id="testme"
with style="border:1px dashed red;padding:4px;"
with align="center"

Known Workarounds: None.

Related Issues: None.

Bug/Site Feedback |
Submit a bug

bug 163 - no valign in table cells in IE8

Issue: #163
Affects: IE8 Beta 1
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 173 - form field focus issues in Safari

Issue: #173
Affects: Safari 3.1 (Win), {Safari 3.1 (Mac)?}

As more and more applications go online in this Web 2.0 world, interactions with forms are critical to an applications success. Safari leads the way with built-in textarea resizing but it has a major issue with form field focus.

Since data entry in forms is a crucial part of online forms, ensuring that your forms are both keyboard and mouse navigable is important. Unfortunately in Safari the keyboard navigation breaks if you use the mouse on radio or checkbox elements. This becomes a major issue because although radio and checkbox elements are keyboard accessible, in general users prefer to use the mouse to make their selection(s).

The issue is this. If you use the mouse to select a radio or checkbox field one expects that that field has the focus and thus a 'Tab' will take you to the next available field (or whatever is defined in the tabindex order). When the user presses 'Tab' in Safari, the focus resets to the first form field on the page!

If you use the mouse for other types of fields, or use only the keyboard the issue doesn't occur.

Example: (Try it out!)

First Name:
Last Name:
Email:
Life Story:
Gender:
Female
Male
Pets Name:
Spam Preferences:
Pornography (NSFW collection)
Medications (weight loss, ED, muscles)
Mortgage/Loan (impossible rates)
Religion (guilt, pressure, overtones)
Fakes (fake rolex, cartier, artwork)
Hot Stocks (buy! buy! insider info)
Pirated software (OEM, Bulk, Download)
Illegal Music/Movies (Torrents, P2P)
Surprise Me! (Scams, popup, virus)
Address Line 1:
Address Line 2:
Comments:

Known Workarounds: None.

Related Issues: (bug 132).

Bug/Site Feedback |
Submit a bug

bug 403 - another getElementsByName() bugs in IE

Issue: #403
Affects: IE6, IE7

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.gorms[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 385 - valid CSS class names that fail in IE6

Issue: #385
Affects: IE6

In IE6, attempting to use a valid class name that starts with an underscore will fail.

Example:

<style type="text/css">
  ._myCSSClass {
    /* This is a valid Class Name, but it will fail in IE6 */
    border: 1px solid #ff0000;
    margin: 1px;
    padding: 3px;
  }
</style>

Known Workarounds: None. The only option is to name all classes with an initial [a-zA-Z] character.

Example Workaround Code:

<style type="text/css">
  .myCSSClass {
    /* This is a valid Class Name, AND will work in IE6 */
    border: 1px solid #00ff00;
    margin: 1px;
    padding: 3px;
  }
</style>

Related Issues: None.

Bug/Site Feedback |
Submit a bug

bug 371 - named anchor links are broken in IE8

Issue: #371
Affects: IE8 Beta 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 To be Fixed in: IE8 RTM (not the CSS3 opacity... likely a return to filter:alpha())
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: None.

Related Issues: None.

Bug/Site Feedback |
Submit a bug

Will IE8 fix IE's DOM Support issues - Poll Results

Will IE8 fix their DOM Support:

In our last poll, we asked if you felt that IE8 would fix their DOM Support? The poll was live long before the IE8 Beta 1 came out and thus nothing was known about the new version since Microsoft isn't very forthcoming with sharing a road map with developers.

Regardless, the mood of the development community was reflected in the results that came in before the beta release, and was only slightly different after developers got some first hand experiences.



Results:
Yes Completely - 4%
Not A Thing - 16%
Minor Fixes Only - 15%
Mostly Fixed - 3%
Fix Some, Break Some - 30%
I Don't Care Anymore - 5%
Don't Make Me Laugh - 27%

To be honest, most were taken back by Microsoft's commitment towards standards, and actually taking the (correct) brave step to render in Standards Mode by default.

Many of the long standing bugs DOM Bugs were fixed, although there were many that didn't see any attention at all. New features were added, but the overall UI was hardly improved upon at all (from legacy chrome/usability bugs, to the un-movable toolbar issues).

If history of IE7 development is to repeat itself, expect a few more betas for IE8, then an RC (Release Candidate), and a final RTM (Release To Market) date sometime late in Q4, 2008 or Q1, 2009 if they continue to fix ignored issues.

As noted here day 1, we promised to link into the public bug tracking systems for each browser, when and where they became available (and we certainly have done so - if you find a bug listed here that doesn't reference the IE Feedback bug number, please let us know!). When IE8 Beta 1 was released, Microsoft re-opened their "IE Feedback" site at Microsoft Connect, so that developers could view and track bugs with input from Microsoft. It isn't a full public bug tracking site, but it has been dearly missed since it was dismantled after the IE7 release, in fact one of the reasons that this Blog started! ;-)

We hope that the IE Feedback site will stay open forever (or some similar site) so that developers can continue to benefit from its presence, however when directly questioned, the response was less than an absolute yes on the IE Blog.

We wish the IE Team the best of luck on shipping IE8 with great DOM Support to an eager developer base, lets just hope we can close a bunch more issues before it is shipped out the door!

Bug/Site Feedback |
Submit a bug