Microsoft reverts their decision to block Flash by default in IE10!

Microsoft reverts their decision to block Flash by default in IE10 - Users and Developers rejoice!

If you've been following along you'll know that Microsoft announced back on September 2011  that IE10 running in what they used to call "Metro Mode" would no longer be running addons including Adobe Flash.

This generated a lot of controversy when announced because IE & Windows supported a lot of legacy websites & applications that depended on Flash.

Even in January 2012 they were still determined to do this (again even with developers complaining)

Again in April 2012 they continued with their mission.

Then they came to their senses in June 2012 and opened up Flash access after working with Adobe to optimize it for better CPU/battery use.

However they still didn't have it right.

They forced developers to go through a painful analysis, testing & registration process in order to request permission to have their site added to a special list (the CV whitelist) that granted permission for the site to run flash.

• They required developers to test on hardware that wasn't commercially available
• They ruined the user experience by taking control away from the user.
• The user would visit a site and the content would be blocked - yet they had no way to know nor any way to enable it if they wanted.

• They used a whitelist instead of a blacklist (classic programming flaw when dealing with billions of anything)

Now in March 2013 they finally addressed the fact that this design decision was a bad one and have reverted their settings so that Flash is actually enabled by default.

Everyone wins!

Users will be able to see/use/interact with the content they intended to view and for the few sites that have issues they've been added to a blacklist (instead of a whitelist) so that they can be better controlled.

A lot can happen in a year and a half! Thankfully Microsoft did the right thing in the end - even if they made Web Developers loose countless nights of sleep in the process.

bug 521 - IE8 won't render in Standards Mode.... if rendered in a Web Slice

Issue: #521
Affects: IE8
Status: Microsoft has confirmed this will NOT be fixed in IE8 RTM

With much rejoice Web Developers everywhere cheered when Microsoft announced that IE8 would render in its best effort at Standards Mode by default when IE8 ships. This is still true, with a few exceptions.

1.) Intranet (e.g. internal network sites) will still render in IE7 mode by default [ITNOBC*]
2.) When you add one of the nifty IE8 Web Slices (e.g. brand spanking new to IE8, never ever supported in IE6 or IE7 before)... even when you serve up 100% valid Standards Based HTML content... IE8 will ALWAYS, Without exception... render it like IE7.

So its another case of 2 steps forward, 1 step back. You can update/maintain your pages to ensure IE8 renders them well just like they appear in Firefox, Safari, Chrome and Opera, etc. but if you want to add one of these Web Slice (think mini-graphical RSS) things to your page, you'd better make sure that that content renders just as well in IE7 mode.

Don't bother with Conditional Comments looking for IE7 though, because the Web Slice "engine" will report itself as IE8.

Developers find it very puzzling that new features are broken right out-of-the-gate when so much focus for IE8 was on fixing the mistakes of the past. Oh well.

Known Workarounds: None.

Related Issues: None.

[ITNOBC]: "In The Name Of Backward Compatibility"

Bug/Site Feedback |
Submit a bug

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 421 - IE fails to pass the HTTP Referer on many navigations

Issue: #421
Affects: IE6, IE7, IE8, IE9 RC 1
Status: Microsoft has confirmed this will NOT be fixed in IE8 RTM

Lets take a moment to explain... The HTTP Referer: Identifies the address of the webpage that linked to it... by checking the Referer the new page can identify where the request came from. (and uhm yeah, the intentional mis-spelling of this header is a whole other issue)

(Full Wikipedia Referer Def'n and the HTTP/1.1 spec on Referer)

All good browsers send this header on a request indicating where the request came from. The target page/site can then use that information to track backlinks, gather stats on where their users are coming from, improve their marketing, or even block links from an undesired source. Within a site it is handy also to determine the best place to send a user back to, as they may have arrived from any number of sources.

So, what's all the hoopla about? Well IE doesn't always send it. In fact there are several cases when IE doesn't send it, but the most common is this one.

Example:

<input type="button" value="Edit" onclick="location.href='edit.html';">

If you click that button in any non-IE browser, it will tell you what site/page you just came from. However if you click that button in IE (even if you cross your fingers and click with your left hand) no HTTP Referer information will be sent.

So in the larger picture if you want to do any navigation in JavaScript, be ready for it to not pass the referer.

Known Workarounds: One. If you create your own page navigation function in JavaScript and use it instead you can force IE to send the Referer. (It won't help you obtain it from any other site that doesn't provide their own fix though)

Example Workaround Code:

//use browser sniffing to determine if IE or Opera (ugly, but required)
var isOpera, isIE = false;
if(typeof(window.opera) != 'undefined'){isOpera = true;}
if(!isOpera && navigator.userAgent.indexOf('Internet Explorer')){isIE = true;}

//define for all browsers
function goto(url){
  location.href = url;
}

//re-define for IE
if(isIE){
  function goto(url){
    var referLink = document.createElement('a');
    referLink.href = url;
    document.body.appendChild(referLink);
    referLink.click();
  }
}

In this case we define a new function called goto(url) for all the browsers it just sets the location.href to the new value, but in IE we redefine it, so that it creates a link, appends it to the DOM, then simulates a click on that link causing page navigation to occur but since IE does pass the referer on links, the referer is sent to the target page!

(PS for those waiting on the Fish Bicycle, it is coming soon... this bug isn't it)

Related Issues: None.


Bug/Site Feedback |
Submit a bug

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

Issue: #342
Affects: IE7, IE8

Update: It is well known that addon/extensions slow down IE. Disable any that are not required. In particular, MS Research is very slow and not needed.

Note: IE is still extremely slow after disabling addons, but the speed will improve.
Status: Microsoft has confirmed this will NOT be fixed in IE8 RTM



Normally the bugs posted on here deal with the content served up to the browser in HTML, CSS & JavaScript.

However Today's bug is about opening a new Tab in IE7/IE8, and the fact that it takes a V-E-R-Y long time (read:unacceptable), while "Connecting..."

Now we would be okay with the slowness if it were downloading something complex like the Digg or Slashdot, front page... but this happens opening the "about:blank" page!

For those unaware, the HTML code for the "about:blank" page is listed below.

"about:blank" HTML:

<html></html>

(That's it folks! No JavaScript!, No CSS!, No Head!, No Body!, Nada, Zip, Zilch!)

What is really frustrating with this, is that it seems to lock up resources while loading thus making it very hard to do anything else while the new tab is loading.

The final blow comes when you are opening the new tab, to paste in a new URL. If you paste it in reasonably quickly, it will kind of get there, but then get overwritten with "about:blank"... and IE can't load the page so you need to re-select the URL and re-paste it in to get to the site you wanted.

Usability is apparently one of the key objectives in IE8, so lets hope that this gets fixed before IE goes RTM. ;-)

Addition: By default in IE8 Beta 2, the "about:Tabs" page appears for a new tab, with a collection of additional items/options. This page is very slow also, but setting it to use "about:blank" doesn't speed things up.

Known Workarounds: None.

Related Issues: None.


Bug/Site Feedback |
Submit a bug

bug 126 - no W3C DOM Level 2 Event Listeners

Issue: #126
Affects: IE6, IE7, IE8
Partially Fixed in: IE9 RC 1 (events are still not possible on option/optgroup elements (bug 280))
Status: Microsoft has confirmed this will NOT be fixed in IE8 RTM


MSIE Feedback ID: 333958



The W3C published the specs for (W3C DOM2 Event Listeners) on or before November 13th, 2000. This means that the spec has been available for over seven years. When it wasn't present in IE6, the development community couldn't complain. When it was omitted from IE7 (they were still too busy trying to catch up) it was unfortunate, but accepted. However we are now at the dawn of IE8 (currently in Beta) and there is still no sign of DOM2 Event Listeners. Therefore this is no longer just a "we haven't had the time yet" or "we have higher priorities" issue, this is now a genuine bug!

Example:

<script type="text/javascript">
  var obj = document.getElementById('foo');
  obj.addEventListener('click', myClickHandler, false );
</script>

Known Workarounds: One. Create your own "addEvent" function that attempts to best handle IE's missing implementation by wrapping "attachEvent" in a cross-browser implementation.

Example Workaround Code:

  //soon

Related Issues: (bug 186).

Bug/Site Feedback |
Submit a bug

bug 132 - slow checking checkboxes required in IE

Issue: #132
Affects: IE6, IE7, IE8, IE9 PP4
Status: Microsoft has confirmed this will NOT be fixed in IE8 RTM

Checkboxes are the perfect form control to select multiple items. In fact they are so good, that the original element designed for this (<select multiple="multiple">) is hardly used because it is so user unfriendly.

They get used everywhere, especially in a long list of items (it could be emails, tasks in a TODO list, or picking your any number of options).

However there is a bug in IE, that forces you to make sure you pick options slowly. The bug is that if you press the Tab key, and the Space bar at the same time, the checkbox control gets "locked" in a strange state, renders "disabled", and stops any other interaction with the rest of the form, the page, the toolbars, the menu or even the window itself!

So, lets analyze this. First off, why would a user press Tab + Space on a checkbox in the first place? Well, if you want to check/uncheck a series of checkboxes quickly, you can Tab through them, and press the Space bar to toggle their status. Once you've mastered this trick, you'll find yourself using it all over the Web.


Example:


Then Tab to the checkboxes, press Space to toggle them, then press Tab and Space at the same time on one.
One
Two
Three
Four
Five
Six
Seven
Eight

Known Workarounds: None. There's no workaround for this issue from a programming perspective, but you can as an end user, press Escape to clear the lock.

Related Issues: None.


Bug/Site Feedback |
Submit a bug

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

Issue: #210
Affects: IE6, IE7, IE8, IE9 RC 1
MSIE Feedback ID: 336254 |
MSIE Feedback ID: 332545
Status: Microsoft has confirmed this will NOT be fixed in IE8 RTM

Back Story: Explanation as to why innerHTML doesn't work - by the guy that wrote it!


Internet Explorer generally works best, when you pass it new content via the .innerHTML property. This is mainly due to many bugs in the DOM methods that would otherwise be preferred. However .innerHTML has its own problems, and IE has some strange issues using .innerHTML.

In IE, you can not use .innerHTML to set the contents of a table ,thead, tbody, tfoot element, or a tr element, because IE makes them readonly (Problem Report | MSDN Bug data).

Known Workarounds: Three.

Option 1:
Using the DOM methods instead {createElement, appendChild, etc.}, but remember that in IE, although you can code your HTML documents with a (table > tr > td) structure, you can't do that when building the DOM in JavaScript in IE!

In IE, you must create the structure in this format (table > tbody > tr > td) note the tbody is required. IE will not throw any error if you omit it, but it won't render the content either (bug 171).

Option 2:
As Anonymous pointed out, you can wrap the table in a '<div>' element, and set the .innerHTML on it (don't forget a '<tbody>' element to wrap the rows though.

Option 3:
In a similar fashion, you can set the .outerHTML of the table element instead (same catch for '<tbody>' applies). The advantage here, is that you don't mess up your DOM structure which might upset any CSS rules that were not expecting a div. The big catch here though, is to remember that .outerHTML is a proprietary feature of IE, thus if you use this technique, you'll need to ensure that you are only applying this to IE, not globally to all browsers.

Related Issues: (bug 124), (bug 171).

bug 109 - JavaScript prompt() in IE - How did this not get fixed in IE7?!

Issue: #109
Affects: IE5, IE5.5, IE6, IE7, IE8, IE9 PP1, IE9 PP2, IE9 PP3, IE9 PP4, IE9 RC 1
Note this issue affects all versions of IE, but any version of IE below 5 is ignored.
Status: Microsoft has confirmed this will NOT be fixed in IE8 RTM

MSIE Feedback ID: 333954

The JavaScript prompt() method has been in Web Browsers that support JavaScript since day 1. The concept is simple. Provide a modal dialog, that displays a message, and allows the user to input a value.

Example: (from Firefox)

prompt() dialog in Firefox 2 on Windows XP

prompt() dialog in Firefox on Windows 95/98/98SE/ME/2000

You've seen a "prompt" dialog of one kind or another in almost every windowed computer application in existance. It is by far, the easiest way to "halt" current activities, and ask the user for a value.

Unfortunately, this dialog, the "3rd trickiest" of the (only 3) available JavaScript dialogs in the web browser, is horribly broken... in fact, it hasn't even been patched once since its original design, made available in 1995! (That's 12 years ago for those without calculators!)

---

So, how is it broken?

1. Display position is wrong, and awkward


2. Button display is inconsistant with other dialogs


3. The text input box is extremely large (redundanly so)


4. The dialog does not scale


5. The message in the dialog gets truncated


6. The dialog does not declare the hostname of the site that launched it


7. Did we mention that it is ugly?


8. Whats with the title and the "script prompt" line?


9. Where is the icon for this message box?


10. Oh, and it doesn't handle DBCS (Double Byte Character Sets)


11. (bug 139) - It doesn't center on the browser window

Try it yourself! Create new folder

Compare it with the alert() and confirm() dialogs

Now lets take a look at each of those closely:

1 Display Position

If every other utility dialog appears nicely centered in the browser display, why does the prompt dialog appear about 50px from the top left corner of the screen? How is this consistant? Would this not likely cover the most important content on the screen below, such that the first thing a user would need to do is move it to see what the prompt is related to?

2 Button Display

What is with the odd right-aligned stacked OK/Cancel buttons? Is this typically used anywhere else in Windows? No! So why does this dialog need to differ? What happened to consistancy for the user?

3 Text Input Box Size

Are users expected to write a novel in this dialog? What if the prompt is "How many books would you like to order?" This input suggests that only numbers in the {Seventy trillion billion...} are expected. We don't think that the text box should be small, but this box is like 1/3 to 1/2 the screen size!

4 Dialog does not scale

If you have a large message, the dialog doesn't stretch to accomodate it, like the alert() or confirm() dialogs do. Considering that scaling was implemented for these 2 dialogs, would it not have occured as an important consideration when designing the prompt dialog?

5 Hostname not declared

This is a new feature of modern web browsers, designed to help alert users to any odd XSS (Cross Site Scripting) hacks that might get them to divulge sensitive information. AFAIK, Opera was the first to have this, with Mozilla Firefox following suit. Developers were quite confused when IE7 shipped without adding this simple security feature.


6 The message in the dialog gets truncated

prompt() dialog in IE7 on Windows XP

prompt() dialog in IE 5/6 on Windows 95/98/98SE/ME/2000

This (due in part because of #4 above) is the biggest issue. Presenting any message other than "How many", or "What is your name" requires some thought because if your message is anything longer than a quick sentence, the content will get truncated!

7 Ugly. Just plain ugly

Normally a feature being ugly doesn't count as a bug, but in this case I disagree. Since the dialog does look ugly, and has not changed in 12 years, it highlights that this browser (now in version 7) hasn't been given the attention it needs and is not up to par with modern browsers.


8 Title / message

Why is the title "Explorer User Prompt" instead of "Microsoft Internet Explorer"?
What is the "Script Prompt" all about?
This dialog is not very user friendly.

9 Missing message box icon

Standard message boxes (mini dialogs) like this in Windows have an icon. The .alert() dialog has an exclamation icon, the .confirm() dialog has a question mark icon etc. So where is the question mark icon for the prompt dialog?

Sample dialogs:

Firefox .alert();

Firefox .confirm();

Firefox close tabs dialog

Yet another IE dialog with an icon

10 No support for DBCS (Double Byte Character Sets
You can see this article on MSDN for more details, but there is no realistic workaround available.

As Web Developers build their sites and applications (which are getting more and more complex) it never ceases to amaze them that such a simple borwser feature has been given such neglect.


Example:

<script type="text/javascript">
  prompt('You need to enter a name for this new mailbox.\n' +
    'Please ensure that it does not contain spaces quotes or the percent symbol.\n' +
    'You can change the name at a later time if desired.','Friends');
</script>

Known Workarounds: None. You can attempt to simulate a dialog, for user input using floating elements above the page, however you will need to build the entire "dialog" and will have to add code to enable draging etc.

Related Issues: None.

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

Issue: #256
Affects: IE5, IE5.5 IE6, IE7, IE8, Opera 8.2, Opera 9.2
Fixed in: Opera 9.50 alpha 1 build 9500
MSIE Feedback ID: 339307
Status: Microsoft has confirmed this will NOT be fixed in IE8 RTM

The ECMAScript specification for the DOM provides a set list of element types or nodeTypes... Text Elements, Node Elements, Comments, etc. They are numbered integers, with a Constant defined for easy to read comparison purposes. The only problem is, that they are not Constants at all, in IE or Opera.

NodeTypes:

interface Node {
  // NodeType
  const unsigned short      ELEMENT_NODE                = 1;
  const unsigned short      ATTRIBUTE_NODE              = 2;
  const unsigned short      TEXT_NODE                   = 3;
  const unsigned short      CDATA_SECTION_NODE          = 4;
  const unsigned short      ENTITY_REFERENCE_NODE       = 5;
  const unsigned short      ENTITY_NODE                 = 6;
  const unsigned short      PROCESSING_INSTRUCTION_NODE = 7;
  const unsigned short      COMMENT_NODE                = 8;
  const unsigned short      DOCUMENT_NODE               = 9;
  const unsigned short      DOCUMENT_TYPE_NODE          = 10;
  const unsigned short      DOCUMENT_FRAGMENT_NODE      = 11;
  const unsigned short      NOTATION_NODE               = 12;
  //...
}

Example:

<script type="text/javascript">
  var obj = document.getElementById('someID');
  var textContent [];
  for(var i=0;i<obj.childNodes.length;i++){
    if(obj.childNodes.item(i).nodeType == TEXT_NODE){
      textContent.push( obj.childNodes.item(i) );
    }
  }
  alert('The inner text without HTML tags is: ' + textContent.join(', '));
</script>

In a spec compliant browser, the code should be able to test against the TEXT_NODE constant.

Known Workarounds: One. It is extra processing, but each element type can be defined as globals at the begining of every page.

Example Workaround Code:

<script type="text/javascript">
  (function(){
    var NodeTypes = ['ELEMENT', 'ATTRIBUTE', 'TEXT', 'CDATA_SECTION',
                     'ENTITY_REFERENCE', 'ENTITY', 'PROCESSING_INSTRUCTION',
                     'COMMENT', 'DOCUMENT', 'DOCUMENT_TYPE',
                     'DOCUMENT_FRAGMENT', 'NOTATION'];
    for(var i=0i<NodeTypes.length;i++){
      window[NodeTypes[i] + '_NODE'] = (i + 1);
    }
  })();
</script>

Related Issues: None.

bug 237 - type is a readonly attribute in IE

Issue: #237
Affects: IE5, IE5.5, IE6, IE7, IE8, IE9 PP4
MSIE Feedback ID: 332453
Status: Microsoft has confirmed this will NOT be fixed in IE8 RTM
Partially Fixed In: IE9 Platform Preview 6 (only when rendering in IE9 Standards Document Mode)

Update: There are partial fixes for this in IE9 Platform Preview 4. For example you can change an input element from text to hidden and back to text and it works. However changing any input type to a password, then back to any other type deletes the value attribute contents (e.g. erases the set value)

In a world of Web 2.0 shininess, being able to work your JavaScript-Foo on the DOM is critical. A typical, yet simple example of this, would be to change an input type="text" element on a form, to a type="hidden" field, or visa versa.

Example:

<input type="text" id="userid" value=""/>
<script type="text/javascript">
  var userIDField = document.getElementById('userid');
  var userID = userIDField .value;
  //do some fancy ajax stuff...
  userIDField.setAttribute('type', 'hidden');
</script>

In a DOM compliant browser, this is a piece of cake. However in IE (msdn article), the type attribute is read-only... except for a small window of time before you add an element to the DOM (e.g. if you are using createElement() )

Known Workarounds: None. If you copy all the information for a given node, into JS variables, then remove the existing element, and create a brand new one in its place, then you are set.

However the sheer complexity of this task makes it rather troublesome even to attempt. Keep in mind, any workaround should handle all attributes set on the element, including custom attributes and attributes in specialized namespaces. Also remember that any event handlers attached to the element need to be copied over to the new element. If you think you have an ideal workaround, drop us a line!

Related Issues: (bug 242).

bug 411 - getElementsByName doesn't work in IE

Issue: #411
Affects: IE5, IE5.5, IE6, IE7, IE8
Status: Microsoft has confirmed this will NOT be fixed in IE8 RTM

MSIE Feedback ID: 334336

Example:

<script type="text/javascript">
var checkboxOptions = document.getElementsByName( 'preferences' );
alert( 'There are ' + checkboxOptions.length + ' preference options.' );
</script>

Known Workarounds: No direct methods.

Example 1 Workaround Code:
Developers must iterate over all potential tag matches with a call to getElementsByTagName(), then for each NodeList returned, check for a match against the name attribute with getAttribute( 'name' ). Alternatively, if retrieving elements from a form by name, formObj.elements[name]; will return a form element array that will suffice.

Example Workaround Code:

<script type="text/javascript">
//option 1
var inputs = document.getElementsByTagName( 'input' );
var checkboxOptions = [];
for(var i=0;i<inputs.length;i++){
  if(inputs.item(i).getAttribute( 'name' ) == 'preferences' ){
    checkboxOptions.push( inputs.item(i) );
  }
}
var checkboxOptions = document.getElementsByName( 'preferences' );
//option 2
var checkboxOptions = document.forms[formIndex].elements['preferences'];

alert( 'There are ' + checkboxOptions.length + ' preference options.' );
</script>

(Note: If there is only one checkbox, using option 2, the length will be undefined, since browsers treat a single checkbox as an atomic item, but multiple as an array)

Example 2 Workaround Code:
Since IE keeps an associative array in the proprietary document.all object, we can carefully iterate over it to solve this issue. (in theory, code below is untested)

<script type="text/javascript">
//use browser sniffing to determine if IE or Opera (ugly, but required)
var isOpera, isIE = false;
if(typeof(window.opera) != 'undefined'){isOpera = true;}
if(!isOpera && navigator.userAgent.indexOf('Internet Explorer')){isIE = true);

if(isIE){
  var document._getElementsByName = document.getElementsByName;
  document.getElementsByName = function(name){
    var temp = document.all[name];
    var matches = [];
    for(var i=0;i<temp.length;i++){
      if(temp[i].name == name){
        matches.push(temp[i]);
      }
    }
    return matches;
  };
}
</script>

In theory, this should work, but it might need adjusting, if there is only 1 item with the name, and that item, has a length property (e.g. a form, a select list, a radio button or checkbox set.) If you find the perfect solution, please advise.

Related Issues: None.

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

Issue: #274
Affects: IE6, IE7, IE8, IE9 PP4, IE9 RC 1
Trackers:
MSKB Tracker: 276228

MSIE Feedback ID: 336252
Status: Microsoft has confirmed this will NOT be fixed in IE8 RTM

There is actually several issues with select list elements in Internet Explorer. See the Related Issues section for other issues.

This issue, is the fact that setting the .innerHTML on a select element does not work, and actually appears to render NO options in the list. Some will argue that the .innerHTML property isn't a DOM Method (true), but it has been adopted as a standard method to quickly populate the DOM Fragment inside of an element.

Example:

<script type="text/javascript">
  var myOpts = '';
  for(var i=1;i<32;i++){
    myOpts += '<option value="' + i + '">April ' + i + '</option>';
  }
  var myDaysSelect = document.getElementById('daySelect');
  myDaysSelect.innerHTML = myOpts;
</script>

Select Day:initializing...

(the select should populate with options for the days in April - including the bonus April 31st! - In IE any original options are wiped out and none of the new ones are added)

Known Workarounds: One. Apparently you can add the actual select element content to your string (pre and post) then set the .outerHTML value. NOTE: This will trash any event handlers you have on the original element.

Example Workaround Code:

  Not going to post.  Most advise against this workaround.

Related Issues: (bug 116).