bug 593 - IE leaks all your windows mouse movements

Issue: #593
Affects: IE6, IE7, IE8, IE9, IE10

Internet Explorer leaks all your mouse movements regardless where in Windows they occur.

There's a lot of discussion about this bug at the moment as any browser bug that gives a website access to any information outside of the browser sandbox is considered a security bug.

In this case IE's classic legacy single global event model has an issue whereby the mouse movements in Windows are fully available to Internet Explorer even if they originate outside of the browser viewport, and even the browser chrome, even when IE doesn't have the active focus... even on a 2nd/3rd screen if you have a multiple screen desktop!

At the same time certain specific keystrokes are also leaked... the SHIFT, CTRL & ALT keys.

Full details of the bug specifics can be found over on the Spider.io blog: http://spider.io/blog/2012/12/internet-explorer-data-leakage/ and there is even a demo http://iedataleak.spider.io/demo

Microsoft has responded to this bug on their IE Blog IE Information leak and Security Issue however they are not taking the issue very seriously... rather trying to dispel the severity of the issue and imply that the bug report is only the result of an ad network that is fearing that this issue is affecting their competitive ability.

We'd really prefer if the politics of business stayed completely out of this discussion.  The bug has been responsibly reported, vastly ignored by Microsoft and then ultimately disclosed to the developer public when talks with Microsoft were not moving fast enough.

So lets get hypothetical - just what could one do with this info?  Well we can use JavaScript to determine the exact version of Internet Explorer, we can also determine the desktop extents and browser window extents.

We can fairly accurately track movements to anywhere within the browser chrome to see if the user goes to click on the zoom controls or the JavaScript error icon in the bottom left...

We could capture events near the "Red X" of the browser window to block users from being able to easily close their browser... know when they are going to their address bar or search bar... the desktop taskbar/start button...

Any combo of ALT key followed by navigation to the top left portion of the IE chrome would indicate access to some part of the IE menu... followed by fairly precise movements would expose which menu options were accessed...

Can you think of other potential things that could be tracked? Let us know in the comments.

Meanwhile lets hope that Microsoft really is taking this seriously now that it has gone public and that a priority patch for all versions of IE is available before Christmas.

Known Workarounds: None.

Related Issues: None.
Bug/Site Feedback | Submit a bug

IE10 for Windows 8 to be released on October 26th, 2012

IE10 for Windows 8 to be released on October 26th, 2012.

For developers keeping up to date on IE developments this likely isn't news however there's lots of new things coming that developers need to be aware of.

For starters even though it won't be available on the Oct. 26th launch date there is a version of Internet Explorer 10 coming to Windows 7.  There's been no confirmation from Microsoft yet but there has been a preview announced for Windows 7 in mid November (lets call that Nov.15th) which would suggest at the earliest an RC (Release Candidate) in December and an actual release by January 2013.

What this means is that Web Developers need to be ready to support IE10 even if they haven't yet downloaded the Windows 8 RTM preview OS they probably really should go get a copy as the promised Windows 7 version is way behind schedule.

3 Versions?

A lot is changing in IE10 so lets take a moment to go over the highlights.  For starters there are (or at least will be) 3 versions of IE10. IE10 for Windows 7, IE10 for Windows 8 in Metro Mode and IE10 for Windows 8 in Desktop Mode.

The most interesting (and also most controversial) is IE10 for Metro.  It provides the perfect full screen touch friendly interface for the upcoming Windows 8 tablets including the tablet that Microsoft calls "The Slate" (Forgive me while I LOL thinking about The Flintstones or any other ancient reference.

On the positive side Microsoft added Back/Forward navigation overlays at the middle of the screen on the left and right sides perfect for thumb navigation while holding the tablet... and the full screen mode helps the user dive right in on the content they are viewing.  While on the tablet you can use gestures similar to those on the BlackBerry PlayBook or some Android devices to swipe up/down from the bottom/top of the screen to expose the location bar and a thumbnail list of your active tabs.

On the negative side (yeah you knew there would be one right?) there are several usability issues that affect IE10 and Windows 8 that your users might not realize are due to the browser/OS and not your site.

Before we get into the details of each one its important to understand "how we got here" and thus the back story as best understood by the collective Internet (as Microsoft has failed to provide the story themselves).


The Story:

In developing their next Operating System Microsoft realized that they were starting to significantly lose their dominance in the market.  Apple was making a major comeback with sexy hardware, an OS that just worked and 3 little things called the iPod, the iPhone and the iPad.  In fact that last device, the iPad was inventing an entirely new market and Apple was taking it all by storm!  This was upsetting to Microsoft as they had tried to create this market years ago and had failed... and their music player that they had recently built (the Zune) had failed to take any market away from the iPod.  Microsoft was in serious trouble and even they knew it this time.

They needed to make a tablet that could compete in the market and somehow use their desktop dominance to help upsell the tablet and so they realized that being able to use the full Windows desktop on the tablet (not just a VNC/Remote Desktop) was needed - and that would be their biggest selling feature!  However the UI from Windows (even Windows 7) simply wouldn't cut it on a tablet as it was never meant to be driven by touch as a keyboard and mouse provided so much more control.  The solution was to add the UI from their flailing Windows Phone device (even though Microsoft themselves had admitted it was a failed design) that had some very compelling usability features to the tablet and thus kill 2 birds with 1 stone giving both the phone and the new tablet a consistent look and feel.

However now there was a new problem... Microsoft wanted to make the tablet and the desktop version of Windows to have a consistent look to help lure consumers into buying a Windows Tablet when it shared similarities to the desktop they would be familiar with... and thus they decided that both the tablets and the PCs would both have the "touch friendly" Metro interface by default... but both would also have the full blown desktop experience hiding just underneath.  Conceptually this was a massive marketing win and I don't blame Microsoft for taking this approach to try and C.T.A.

The Analysis:

Wait! What? But won't that make 1/2 of the experience on the tablet suck... and the other 1/2 on the desktop PC suck? - why yes... exactly!

There's a very good reason why the iPad was so successful.  It was pre-seeded with 1,000's of iPod/iPhone apps when it was released and the UI was simple, designed entirely for touch... the UI was tailored to the device and the form factor.

Metro is simple too (its just a bunch of squares and rectangles) in fact many think it is too minimalistic... there's no "love" for this UI... no shadows, no rounded corners, no glossy igons, not even shadows or the most basic of 3D effects... you know, the ones that afford usability by making a button so obviously click-able vs. a flat rectangle that isn't.

The classic "desktop" experience on a tablet however... just plain sucks.  It's not touch friendly and anyone that has used VNC or similar tools on an iPad knows that its handy to be able to use a desktop app in an emergency but no one in their right mind would want to do this regularly by choice.

The reverse is also true.  Desktop users love their PCs because they can do anything and get things done. Data entry? you bet! 3D Modeling? yup! Spreadsheets and Databases... legacy Enterprise apps - yeah it all just works.  Metro on a desktop though is clumsy... there's no options for "power users" and unless your boss wants to let you play Angry Birds and other games all day... 99% of Metro will be "fluff" to you.

Wow... so much info to explain and digest.  I think I'll save the really technical details for another post (and I'll add a link below once posted).

(Link to part 2 - The technical details)

In the meantime if you've already tried out Windows 8 and IE 10 let us know your thoughts... have you tested your sites and apps?

Bug or Feature - Round Six

Round Six Enabling the non-Disabled.

Other rounds: [One|Two|Three|Four|Five|Six]

We're back again with another round of "Bug or Feature?" highlighting a particular behavior in one or more browsers, that, well, could be a Bug, or it could be a Feature... we'll open up the comments for your vote and opinion.

Alright, what's today's "Bug or Feature"?

Synopsis:
Everyone knows that form elements [button|input|select|textarea] can be disabled to stop users interacting with them and to ensure they are not "successful controls" when a form is submitted.

So... what happens if you disable non form elements?

In most browsers... Just like you'd expect... absolutely nothing because it isn't supported.

However in IE there is a different behavior.

In IE when you set the disabled flag on an element it "kinda-sorta" disables all the child elements.

Example:

<div disabled="disabled">
  Email:
  <input type="text" name="foo" value="bar"/><br/>
  Send me spam:
  <input type="checkbox" name="baz" value="yes" checked="checked"/><br/>
</div>

So is it expected that the child elements render disabled? What if you wanted one or more of the children enabled?

Known Workarounds: None.

Related Issues: None.



Bug/Site Feedback |
Submit a bug

bug 196 - IE9 fixes almost .setAttribute('type', value);

Issue: #196
Affects: IE9 PP4, IE9 Beta, IE9 Platform Preview 6

We're happy to say that IE9 has brought many, many improvements to Internet Explorer in terms of updating the IE engine to properly handle standards based code.

IE had issues in the past with the Element.setAttribute(name, value); method for a long time not supporting it on a wide array of elements (bug 242) of which the type attribute was a significant one (bug 237).

We were hoping that after IE9 Platform Preview 4 was released and we found that the .setAttribute('type', value); method had finally been fixed that the "new" bug with the value being erased when switching an HTMLInputElement from type "password" to "text" would have been fixed 2 public releases later.

Unfortunately it is still broken and thus we're tracking this new issue separately here.

Example:

<input type="password" id="accessCode" name="accessCode" value="bfg10k"/>
<script type="text/javascript">
  function exposeCode(){
    var field = document.getElementById('accessCode');
    field.setAttribute('type', 'text');
    //Oopsie! the value is now gone in IE9!
  }
</script>

Known Workarounds: None.

Related Issues: None.

Bug/Site Feedback | Submit a bug

bug 391 - IE is strict in setting innerHTML but not appendChild

Issue: #391
Affects: IE6, IE7, IE8, IE9 PP3

IE is well known historically as a browser that doesn't follow the strictness of standards well. IE will often let you do things that you shouldn't be able to do (e.g. add a div to a select element)

However there are cases where IE is very picky - although confusingly arbitrary in how and when it decides to be strict.

Take for example the <p> element. By definition, this is an inline element which means it should not contain block elements.

The following however seems to work fine in all browsers (e.g. the "rule" isn't strictly enforced")

Example:

<script type="text/javascript">
  var newHeading = document.createElement('h1');
  newHeading.appendChild(document.createTextNode('I am an H1 element!'));
  myParagraph.appendChild(newHeading);
</script>

However in IE, if you change this to use .innerHTML to set the value IE throws an error.

Example:

<script type="text/javascript">
  var newString = '<h1>I am an H1 element!</h1>';
  try {
    myParagraph.innerHTML = newString;
  } catch(ex){
    alert('Failed: ' + ex['message']);
  }
</script>

Which IE then throws an error with the very helpful "Unknown runtime error" message.

This is repeatable for any block level elements: div, h1, h2, h3, h4, h5, h6, blockquote etc.

This obviously isn't desired markup thus the issue with the error is minor however it could well crop up when you adding either content you are not intimately familiar with (JSON response?) or you know the content but are not aware the container element you plan to drop it into is actually an inline element.

Keep this in mind the next time you encounter an "Unknown runtime error" as it might turn out to be a "known issue" ;-)

Known Workarounds: Two. Either ensure you never try to set the innerHTML of an inline element to a block element or use the appendChild() method instead.

Related Issues: None.

Bug/Site Feedback | Submit a bug

bug 511 - checkbox double click fail in IE

Issue: #511
Affects: IE6, IE7, IE8, IE9, IE10

On the web almost all interaction is based on the single-click concept. You click once to follow a link, you click once to press a button, once to open a dropdown select list, select a radio button or checkbox element etc.

So if you were to double click an element that toggles (e.g. like a checkbox) you would expect the first click to change it from state A to state B... and the second to change it from state B back to state A. (e.g. unchecked - checked - unchecked)

This works as expected in all browsers except IE. In IE double-clicking a checkbox will only switch the state once from A to B.

Example:

Try Double Clicking these options:

Apple
Linux
Microsoft
HP
Dell
Cisco


Realistically this isn't a major issue as most users are unlikely to double click a checkbox... however based on the number of post on web forums and newsgroups about how to stop users from double clicking and re-submitting data - it certainly does happen.

Known Workarounds: None.

Related Issues: (bug 132) (bug 193).

Bug/Site Feedback | Submit a bug

bug 358 - saving web pages is incredibly slow in IE

Issue: #358
Affects: IE6, IE7, IE8

Rendering content in the browser is obviously the main goal of day to day web surfing and web application usage.

There's form interaction, games, Facebook, Mashups & Twitter updates just to name a few.

However when you get a bunch of info/data you care about you likely want to do something with it. Typically you'll want to print, save or export your content so that you have a hard copy or backup.

However exporting is only an option if the web application you are using supports that feature... and printing is a great way to waste trees... but a 500 "page" report is something better suited to be saved to a digital file. Besides maybe you want to manipulate that data in your spreadsheet program before printing it or making a PDF to share.

Alright, easy as pie... just render the page you want and choose Save as from the right click menu file menu.

Should take about a fraction of a second to save the page you are viewing (already downloaded) to an HTML file.

Well not quite! Although Firefox, Chrome, Opera & Safari all do this in milliseconds IE does not. Internet Explorer re-requests the ENTIRE file from scratch. Yes, that's right, re-downloads an EXACT DUPLICATE of your (example) 500 page report!

Needless to say this is a massive waste of bandwidth and user time as they wait for the page to be re-fetched... while staring at the already rendered copy they already have!

Known Workarounds: None. Well I suppose the more technically inclined could view the source... then CTRL+A (select all), then CTRL+C (copy), then CTRL+V (paste) and save in your text editing application of choice - but that seems awfully inconvenient when there is a save as option in the file menu.

Related Issues: None.



Bug/Site Feedback |
Submit a bug

bug 396 - more style tag limits in IE

Issue: #396
Affects: IE6, IE7, IE8

Microsoft Support KB: 262161

You may already be aware that Internet Explorer has some limitations with the amount of CSS it can handle (bug 327) so that you can only load a CSS file up to ~288kb in size and the total number of CSS selectors/style rules can't exceed 4096 but there's more!

IE will also only allow you to have a maximum of 30 style tags on a page! So if you have a site that injects a lot of style tags on the fly for components/widgets you may want to think twice about this approach.

Run this code in IE and note that IE caps out at 30 and doesn't create the addition 70 stylesheet tags.


Example:
(note: this is IE specific code)

<html>
<head>
<script type="text/javascript">
function createStyleSheets(){
  for(i=0;i<100;i++){
    document.createStyleSheet();
    var msg = 'Total Style Sheets = [<b>' + i + '</b>] of 100.';
    document.getElementById('ssCount').innerHTML = msg;
  }
}
</script>
</head>
<body onload="createStyleSheets();">
  <div id="ssCount"></div>
</body>
</html>

How many style tags do you have on your page? Add this bookmarklet to your browser and find out. (note if you run it in IE and it says 30, you may well have hit the limit!)

# style tags

Known Workarounds: None.

Related Issues: (bug 327).


Bug/Site Feedback |
Submit a bug

bug 225 - no support for TBody CSS height or overflow in IE in Quirks or Standards mode

Issue: #225
Affects: IE6, IE7, IE8

The beauty of CSS is that you can take a simple design and enhance it with a style sheet for aesthetics and usability.

A classic enhancement is to wrap table rows in a tbody element that will allow for vertical scrolling when they exceed a certain height.

All you need to do is set 2 or 3 CSS properties.

Example:

<style type="text/css">
  tbody{
    height:100px;
    overflow-x:hidden;
    overflow-y:auto;
  }
</style>

This works great and thus makes the table headers always visible even when the user has scrolled to the bottom of the table.

However in IE there is a catch. If you don't have a DOCTYPE set and thus are rendering in Quirks Mode - IE decides that your tbody height isn't for the entire table contents but instead should be applied to every single row in your table! In fact IE6 & IE7 do the same thing in Standards Mode too. Only IE8 running in IE8 Standards Mode doesn't alter the TR row height.

Sample screenshot from Firefox:


Sample screenshot from IE8 in Quirks Mode (same result for IE6 and IE7 in Standards Mode):


Sample screenshot from IE8 in Standards Mode:


I'm not entirely sure how or why this implementation would have ever made it past an initial code check-in as it is obviously wrong, serves no useful purpose, and I fail to see how this could possibly be helpful to any developer or end user.

Of course this is really just one stumbling block on the way to another. Even if you do render in Standards Mode - IE still won't render the vertical scrollbar on your tbody nor restrict the height and thus you still can't improve the user experience for IE users.

If you do have a simple technique to make scrollable tables work in IE - please submit feedback indicating how. Outside of very complex hacks I haven't seen any that work in IE.

Known Workarounds: None. IE does not support CSS height, overflow, overflow-x, or overflow-y on a TBody element.

Related Issues: None.


Bug/Site Feedback |
Submit a bug

bug 361 - Anchors collection in IE contains invalid members

Issue: #361
Affects: IE6, IE7, IE8

In the days before the DOM Methods we have today we only had access to a few special collections for things like forms, anchors, links, images, etc.

They may not be as sexy as document.getElementById(), but they worked, and still do to this day... and depending what you are trying to access may actually be much quicker and easier.

So to the point, the document.anchors collection contains an array of all the anchors defined in the page.

Anchors by definition are <a> tags with a name attribute specified.

Now for the bug.

As disclosed in (bug 152) IE has notoriously had issues with differentiating between id and name attributes, polluting IDs with NAMEs and vica versa.

Thus, if you have hyperlinks with an id attribute set in IE... you will now have a new member in the document.anchors collection even though there is no name attribute specified! Have lots of links with id attributes set? Then you have lots of extra items in your document.anchors collection.

Of course the interesting twist on this is that in modern browsers, any element (div, table, span, img) with an id attribute set can act "like" an anchor in that you can add it as a hash tag in the URL to auto-scroll to a specific spot however keep in mind that by definition only an <a> tag with a name attribute set is a valid element in the document.anchors collection.

Known Workarounds: None.

Related Issues: None.


Bug/Site Feedback |
Submit a bug

bug 234 - showModalDialog Array returnValue now fails

Issue: #234
Affects: IE6, IE7, IE8

We haven't discovered if this bug is exclusive to VBScript or if it affects JavaScript too (but feel free to update us in the comments if you know).

If you downloaded the latest IE Cumulative Security Update for October 2009 security patch, which "fixed" Microsoft Knowledge Base Article 974455 then you may have noticed that the showModalDialog documentation indicates that the window.returnValue accepts an Array.

However after updating KB974455, there was an undocumented change that now Array return values are no longer allowed.

So what can you do if you depend on this non-standard dialog? Well, the workaround is ugly but there hasn't been confirmation from Microsoft that this bug was introduced - nor that a fix is on the way.

Known Workarounds: One. Use something other than an Array and handle the return value accordingly.

Example Workaround Code:

On the Popup window:

<script type="text/vbscript">
  //was
  window.returnValue = arrayValue;

  //now use
  arrString = Join(arrayValue, ";");
  window.returnValue = arrString;
</script>

On the Calling window (e.g. Opener):

<script type="text/vbscript">
  //was
  retArray = window.showModalDialog( ... );

  //now use
  tempRetArray = window.showModalDialog( ... );
  retArray = Split(tempRetArray, ";");
</script>

Related Issues: None.



Bug/Site Feedback |
Submit a bug

bug 349 - you cant select a radio button in IE if it doesn't have a name

Issue: #349
Affects: IE6, IE7, IE8
Fixed In: IE9 Platform Preview 1

This isn't a major bug since it has such a simple workaround but an odd one for sure.

In short it is really simple. If you add a radio button to your page that doesn't have a name attribute, you can't select it... even if it has an id attribute or even if you pair it up with a <label> tag it still won't select.

Example:

<input type="radio" id="foo"/> <label for="foo">Pick Me!</label>
<input type="radio" id="bar"/> <label for="bar">No Pick Me!</label>

Try it out!
Pick Me!
No Pick Me!

If you are using a non-IE browser it should work just fine.

Known Workarounds: One. Add a name attribute and it works just fine in IE.

Related Issues: None.


Bug/Site Feedback |
Submit a bug

bug 179 - .innerHTML love outside the body is hit and miss

Issue: #179
Affects: IE6, IE7, IE8, Safari 4, Chrome 2

As most developers know, setting the .innerHTML of an element is one of the fastest ways to dynamically set the content of an element. However there are a few issues when setting the .innerHTML on some elements in some browsers.

For example trying to set the .innerHTML on a [Table, THead, TFoot, TBody, TR] in IE it will fail as will trying to set it on a Select, Pre, or even a (Div with overflow:auto).

Thinking outside the <body> tag, there's a few more tags that you might want to set the .innerHTML on.

The <html>, <head>, <title> tags. Now we can argue that the title tag doesn't accept HTML, but well, we'll let the results speak for themselves.

<html>.innerHTML:
Firefox: Works
Internet Explorer: Fails
Safari: Works
Chrome: Works
Opera: Works

<head>.innerHTML:
Firefox: Works
Internet Explorer: Fails
Safari: Fails
Chrome: Fails
Opera: Works (Partially) resets the title but doesn't update styles or scripts

<title>.innerHTML:
Firefox: Works
Internet Explorer: Fails
Safari: Fails
Chrome: Fails
Opera: Works

Known Workarounds: Use DOM methods to update the content of various tags, and document.title to reset the title value. Just keep in mind that there are other bugs with setting the contents of the script tag, and style tag in IE.

Related Issues: None.


Bug/Site Feedback |
Submit a bug

bug 167 - Flash ActionScript communication with IE fails

Issue: #167
Affects: IE6, IE7, IE8

Adobe's Flash /(SWF) uses ActionScript to interact with the browser and your HTML page. In particular you can call a JavaScript function on your page by using the ExternalInterface Object, using the .call(methodName) method.

However although the code is simple to invoke, you may drive yourself bonkers trying to figure out why it sometimes fails in IE.

Example:

  //required imports
  import flash.external.ExternalInterface;
  //...your code...
  ExternalInterface.call('yourPagesJSFunction');//Fails in IE (sometimes)

So how can this simple code work in Firefox and Safari yet fail in IE?

Known Workarounds: One.

The trick is in the unknown requirement... in IE, your <object> tag REQUIRES an ID attribute! The value doesn't matter, but it must be unique (all your IDs are unique aren't they?)


Example Workaround Code:

<object id="anyvalue">

Related Issues: None.

Bug/Site Feedback |
Submit a bug

SVN Access to the IE Code Base for 24 hours!

SVN Access to the IE Code Base for 24 hours!

After all the April Fools' day fun, I had this dream the other night that (Dean Hachamovitch [MSFT]) suffering from a bit of a fever, had taken some over-the-counter medication that was making him feel light headed... and in a moment of inspiration decided that Microsoft should open up access to their code base to let other developers come in and fix some bugs.

The dream was over far too soon as the fever subsided and the access was closed 24 hours later.

However just imagining this brought a smile to my face. I told others and they laughed but agreed it would be great, and then there were those that told me this would never come true... "come on! Subversion Access? Hah! ROFLOL, Subversion! As if!"

What If?

Now lets just say that this magical turn of events did come true. You are provided with 24hours of SVN access to the IE Code Base... What would you want to fix?

Pick 2-3 things that would be first on your list that you would want to fix right away!

PS To Dean I/we wish you the best of health. This in no way whatsoever was meant as a bad thing.

Bug/Site Feedback |
Submit a bug

bug 191 - stack overflow at line: 18 in IE

Issue: #191
Affects: IE6, IE7, IE8

Calling this a "bug" is a bit of a stretch but I wanted to post this so that users encountering this error message have an idea what to look for to fix it.

stack overflow at line: 18, stack overflow at line: 25, stack overflow at line: 41, stack overflow at line:67


It occurs only in IE, when you attempt to run code that runs in an infinite loop. Other browsers seem to pick up the recursion and simply ignore/skip over it without any errors.

It happens most commonly when you attempt to redefine the same method twice, which often happens as a side-issue of overwriting broken IE method implementations.

The actual line number in the message will change, but should be a fairly accurate indicator of where the call is that is causing the infinite loop.

Example:

<script type="text/javascript">
  function fixGetElementsByNameInIE(){
    //save ref to original method
    document._getElementsByName = document.getElementsByName;
    //now redefine it
    document.getElementsByName = function(name){
        var origResults = document._getElementsByName(name);
        //... code to fix it...
        return correctResults;
    };
  }
</script>

If you called fixGetElementsByNameInIE() more than once in IE when you try to actually run document.getElementsByName(name) IE will complain about a stack overflow as it ends up in an endless loop.

Known Workarounds: One. Never re-define a method in IE that points back to itself.

Related Issues: None.


Bug/Site Feedback |
Submit a bug

Bug or Feature? - Round Four

Round Four - Please Don't Stop The Music?

Other rounds: [One|Two|Three|Four|Five]

We're back again with another round of "Bug or Feature?" highlighting a particular behavior in one or more browsers, that, well, could be a Bug, or it could be a Feature... we'll open up the comments for your vote and opinion.

Alright, what's today's "Bug or Feature"?

Synopsis:
The (now deprecated) embed element (use object instead) allows you to embed content in your page like audio and video. Adding audio on demand in your site can be an ideal way to add some multimedia interaction without having to resort to a full blown flash or silverlight plugin.

We can dynamically insert the embed element, and even start it by setting the autostart attribute to true.

If we remove the element, the audio stops, since it is no longer in the DOM... well it stops in Firefox, Safari, Opera, etc. but in IE it keeps on playing and there is no way to stop it. Since there is also a loop attribute that we can set to true, this opens up a very interesting behavior.

So the Question is...

Is this a Bug? Or a Feature?

Vote "Bug" or "Feature", and add your thoughts.

bug 487 - onclick/onfocus bugs on select elements in IE, Chrome & Safari

Issue: #487
Fully Affects: IE6, IE7, IE8, IE9, IE10
Partially Affects: Chrome, Safari

The select form control is great for providing options for a user to select from. You can "enforce" validation simply by what you allow for selection, and the control itself is quite keyboard/mouse friendly with a predictable behavior across all browsers.

Well not quite. IE has a bug with setting an onclick or onfocus event handler on a select element in that if any changes are made to the child options of the select, the first attempt to open the select list with the mouse will fail.

It doesn't matter if you are dynamically populating the selects' options from a JavaScript array or an AJAX request, or removing options that are no longer valid.

In Chrome, the onfocus event works just fine, but the onclick event, won't alter the select field's options until the list is collapsed (e.g. when it closes).

In Safari 4 Beta (need to confirm for Safari 3.x), the onfocus event works fine just like Chrome, but the onclick event never alters the options list at all, no matter how many times it is clicked on.

Try the following samples out, both will not let you open the select list on the first click in IE, and the onclick list will behave oddly in Chrome/Safari. (For this test, we are simply cropping the length of the list) both lists originally have options 100,200,300,400,500,600.

Example:
OnClick Test: 100 200 300 400 500 600


OnFoucs Test: 100 200 300 400 500 600

Known Workarounds: One partial fix would be to use the onmousedown event instead of the onclick event, this will fix the IE issue, but only for mouse interaction. Keep in mind that due to (bug 280) there may be significant challenges creating a workaround for this bug.

Related Issues: (bug 280).


Bug/Site Feedback |
Submit a bug

bug 143 - createTextNode() doesn't work on the style tag in IE

Issue: #143
Affects: IE6, IE7, IE8

Using the DOM to generate elements is ideal, but when you want to generate a style tag, you can't use the DOM methods to populate it in IE.

Example:

<script type="text/javascript">
  var styleTag = document.createElement('style');
  styleTag.appendChild( document.createTextNode('.foo {color:#ff0000;}') );
  var bodyTag = document.getElementsByTagName('body')[0];
  bodyTag.appendChild( styleTag );
</script>

In all browsers except IE, this will append a style element to the page, with the style definition for the "foo" class as the content.

Known Workarounds: One. For IE, we have to divert from the spec., and use the styleTag.styleSheet.cssText property instead.

Example Workaround Code:

<script type="text/javascript">
  var styleTag = document.createElement('style');
  styleTag.styleSheet.cssText = '.foo {color:#ff0000;}';
  var bodyTag = document.getElementsByTagName('body')[0];
  bodyTag.appendChild( styleTag );
</script>

Related Issues: (bug 142).

bug 433 - no Array.indexOf( value ) in IE6 IE7 or IE8

Issue: #433
Affects: IE6, IE7, IE8

As one of the basic JavaScript data types Arrays are great for storing lists of data. You can sort them, push, pop, splice & join them!

However in IE you can't find the index of a value in your array using the native .indexOf( value ) method. Likewise the .lastIndexOf( value ) method won't work in IE either.


Example:

<script type="text/javascript">
  var foo = [];
  foo.push('aaa');
  foo.push('bbb');
  foo.push('ccc');
  foo.push('ddd');
  alert(foo.indexOf('ccc'));
</script>

In good modern browsers this will alert "2" but in IE you will just get an error.

Known Workarounds: One. You'll need to prototype your own. (thanks to jcartledge for pointing out that we missed posting the workaround)

<script type="text/javascript">
if(isIE){
  Array.prototype.indexOf = function(k){
    var len = this.length;
    for(i=0;i<len;i++){
      if(this[i] == k){
        return i;
      }
    }
    return -1;
  };
}

if(isIE){
  Array.prototype.lastIndexOf = function(k){
    var len = this.length;
    for(i=len-1;i>-1;i--){
      if(this[i] == k){
        return i;
      }
    }
    return -1;
  };
}
</script>

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

Bug/Site Feedback |
Submit a bug