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

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

Taking IE6 out to pasture... one step at a time

Taking IE6 out to pasture:

If you are a web developer you've struggled with supporting IE6 for quite some time.

Just how long? Browser Life Statuses

Unfortunately dropping support for IE6 isn't that easy when your end users (and paying customers) are using IE6.

Since many people using IE6 don't have a choice (e.g. they are forced to use it at work) the only way to help push users into newer browsers is to move the entire Internet forward.

Once the momentum of sites dropping IE6 support kicks in... I.T. Admins everywhere will feel the pressure to update their end users PCs to a newer version of IE or even other browsers like Chrome, Firefox, Safari or Opera.

To help track which sites are dropping IE support and thus gauge when you should drop IE6 support (if you haven't already) we're compiling a list here.

If you know of a site that is or has dropped IE6 support please let us know!

Dropping IE6 Support:

Site	Status	Notes
37 Signals	Dropping support for IE6	Dropping IE6 support across all products
CrowdSpring	Phasing out IE6 support	Phasing out IE6 support as of March 2009
Digg	Dropping support for logged in actions in IE6 soon	Much Ado About IE6
Facebook	Suggests IE6 users upgrade	...
Get Satisfaction	Dropped IE6 support	...
GMail	IE6 users prompted to upgrade to Chrome	"GMail runs faster in Google Chrome"
iWork	IE6 unsupported	IE6 unsupported, IE7 support is quirky
LinkedIn	IE6 partially supported	The new rich interface features for LinkedIn will NOT work in IE6 by design
Mobile Me	IE6/IE7 unsupported	IE7 unsupported
Mustardseed Media	IE6 support not included by default	IE6 support by default dropped
Projectturf	Dropped IE6 support	IE6 No Longer supported
Scr.im	No interest in fixing IE issues	Won't Fix
Microsoft SharePoint Server 2010	IE6 won't be supported for editing	IE6 won't be supported for editing
Xero	IE6 support dropped	IE6 is no longer supported
YouTube	Dropping support soon	YouTube next to kiss IE6 Support goodbye
Yubby	IE6 unsupported	IE6 is not supported linked image
Google Apps	Google Apps unsupported	support dropping for IE6 March 1,2010
Zenbe	IE6 unsupported	IE6 is not a very standard compliant browser. We almost have to write a different AJAX UI in order to support IE6. Sorry.

Bug/Site Feedback |
Submit a bug

Internet Explorer first to need a "Fish Bicycle"!

Internet Explorer first to need a "Fish Bicycle"!

*&%$#@! on earth is a Fish Bicycle?

Fish Bicycle:
A Fish Bicycle is just that. A bicycle for a fish.

"But a fish doesn't need a bicycle!" you say?

- Exactly! -

A Fish does not need a bicycle. The idea of a fish needing a bicycle is beyond humorous to the point of gosh darn absurdity.

The term is used in many circles to describe something that is just plain not needed... not yesterday, not now, not ever.

As a developer you may have had a client ask for a Fish Bicycle. They insisted on one of those huge 6 paragraph legal footnotes on every page of a site and every email, or that data get saved to 5 redundant databases "just to be sure".

Did they need it? of course not... it was a Fish Bicycle.

---

So, what's the Fish Bicycle in Internet Explorer you ask? Ah ha! We're about to find out... but not so fast.

A Fish Bicycle in programming is when you need to "give a fish a bicycle" in order to workaround a bug.

For example: If you had to add an <input/> tag to the <head/> of a page in order to add a <div/> to the <body/>, that would be a Fish Bicycle. The body tag shouldn't have any issue adding a div, and the head tag certainly doesn't need an input tag.

Lets see if you can figure it out first! Here's a few clues.

1. It happens in all versions of IE, including IE8 Beta 2


2. It is definitely a bug, no question of that


3. It isn't a bug already reported on Web Bug Track


4. It is a JavaScript issue


5. Oct. 4 - New Tip! It isn't related to any element in the <body/>


6. Nov. 6 - New Tip! It involves popup windows


7. {tip coming...}

Got an idea? Need more info? Ask away in the comments! I'll publish a full writeup in a few days but I want to see if any of the readers can guess it first.

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 404 - Operation Aborted in IE

Issue: #404
Affects: IE6, IE7, IE8

MSDN KB#: 927917

This issue in IE has a deep explanation over on the IE Blog in a post titled: What Happened to Operation Aborted. It is believed to be the source of pain that Sitemeter users were suffering from this past week in IE7.

To sum up, it happens when you use an inline script tag in your page to modify the contents of any of the un-closed ancestor tags of the script tag (excluding the direct parent).

In IE8 they are attempting to fix this, however thus far only the modal error message has been removed, and the page no longer goes blank.

Exact Conditions:

1. The HTML file is being parsed


2. script is executing


3. The executing script attempts to (add or remove) an element from an unclosed ancestor in the markup tree (excluding immediate parent of the script element)

Example:

<html>
<body>
  <div>
    <script>
      var newDiv = document.createElement('div');
      document.body.appendChild(newDiv);
    </script>
  </div>
</body>
</html>

The problem is, this is a very easy scenario to encounter, and to make it worse... if the bug is triggered in an iframe (*cough*, *cough* 3rd party ads anyone?) it affects the parent document, not just the iframe.

To make it worse the dialog is modal, requiring the user to interact with it to close it and when you close it IE navigates to an error page not letting you have a chance to debug it.

Known Workarounds: One. Do whatever you need to do to avoid this scenario. E.g. execute the script after the tag in question has closed, or only alter the script tags immediate parent.

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, IE8 Beta 2, IE8 PR1, IE8 RC1

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
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 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 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 116 - for attribute woes in IE6

Issue: #116
Affects: IE6
Trackers:MSKB Tracker: 314279


The for attribute on a label element will give focus to the related form option, and in the case of radio/checkbox elements, it will select/unselect them. However in IE6, a label with a for attribute linked to a select list will cause a re-selection of the first option instead of just giving focus.

Example:

<label for="colorOptions">Color:</label>
<select name="color" id="colorOptions">
  <option value="1">Blue</option>
  <option value="2">Green</option>
  <option value="3" selected="selected">Red</option>
</select>

Color:

Blue
Green
Red


Clicking on "Color:" should put focus on the selected value "Red" in the select box. However IE6 will give it focus, but select another option, in this case "Blue".

Known Workarounds: One. IE has a proprietary event called "onfocusin" if you attach code to this, you can reset the correct value. However most advise that you try to avoid using the label element for a select list with a pre-selected value in IE6.

Example Workaround Code:
See MSKB Article: #314279

Related Issues: None.

bug 223 - Magical HTTP Get Requests in IE6

Issue: #223
Affects: IE6 (& possibly earlier)
Fixed in: IE7

In IE6, it is possible to send an HTTP Get Request, without using ActiveX, XMLHTTPRequests, AND not have the user know that a request was sent, nor return a rendered response to the user! Welcome to "Magical HTTP Get Requests"!

The trick, is the result of a bug. There should be a visual clue that the request was sent, and also a rendered response.

So what do you need to make these "magical" requests?

1. A hyperlink with an onclick attribute that calls...


2. A JavaScript function that sets the location.href value...


3. and an href attribute with a javascript: protocol value that does nothing

Example:

<script type="text/javascript>
  function doThis(){
    //do any logic you want... then try to go somewhere...
    if(confirm('Do you want to silently go to a Naughty site?')){
      //go there, silently!
      document.location.href = 'http://www.someNaughtyUrl.com/';
    }
  }
</script>
<p>Click the following link in IE6.  You won't go anywhere... visually, but you will send an HTTP Request!
<p>
<a href="javascript:;" onclick="doThis();">Magic Request</a>

If you try this out, you won't see IE6 leave the page you are on. In fact, you won't even see the throbber spin! Best of all, you won't even see the page in your History! but then again, you won't even see the page!

So you might wonder when you would ever encounter such a scenario? Very simple. If you want your link to be properly styled as a link using CSS, you need the href attribute, or it won't look right, show the right pointer cursor, animate on hover, or be tab-able via the keyboard etc. However, you may need to get confirmation before continuing (e.g. "do you want to save your changes?"), other JavaScript logic, or simply create an un-cancel-able request (see web design sidenote #3).

Known Workarounds: One. Change the href link to not include the javascript: protocol.

Example Workaround Code:
Use the hash anchor naming option. If you use a non-existent value, then the browser won't scroll either! ;-)

<a href="#none" onclick="doThis();">This works</a>

Related Issues: None. This issue is also fixed in IE7.

bug 186 - Can't prototype on HTMLElements in IE

Issue: #186
Affects: IE5, IE5.5, IE6, IE7, IE8 Beta 1

MSIE Feedback ID: 333956

Description: The ability to prototype on any HTMLElement (doesn't matter which kind, e.g. HTMLFormInputElement, HTMLFormButton, etc. (see all element types)) is not possible in Internet Explorer. This frustrates many developers because being able to do so would allow them to workaround almost any other bug in IE.

Example: calling HTMLFormElement.prototype.preSubmit = function(){...} will not work, although it works in all other Modern Browsers.

Known Workarounds: None.

Related Issues: Any issue with missing or broken implementations for other elements in Internet Explorer.

bug 137 - IE AutoComplete hardly ever stores data

Issue: #137
Affects: IE5, IE5.5, IE6, IE7, IE8 Beta 1, IE8 Beta 2, IE8 PR1, IE8 RC1
Description: When a form is submitted, by any method other that an input button of type="submit", the data in the form is NOT stored for future use in AutoComplete.

Example: calling document.forms['foo'].submit(); from JavaScript will not save the form contents for future use.

Known Workarounds: According to this KB article KB:329156, explicitly calling this function, before calling .submit(); will store the data in the AutoComplete history.

Example Workaround Code:

function fixSubmit(formObj){
  window.external.AutoCompleteSaveForm(formObj);
  formObj.submit();
}

Related Issues: The workaround for this bug, could be directly incorporated into the .submit() method for all forms on a page, by prototyping a .submit() wrapper on the HTMLFormElement object, however due to bug 186, this is not possible.