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

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 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 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 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 104 - resize event firing errors in IE on Maximize or Restore

Issue: #104
Affects: IE5, IE5.5, IE6, IE7, IE8 Beta 1, IE8 Beta 2, IE8 PR1, IE8 RC1
Partially Fixed in: IE7 & IE8* (see details below)
Fixed in: IE9 RC 1 (in IE9 standards mode only)

The resize event when applied to the window, will fire when the browser is resized.

In IE, it fires continually while stretching a window, and in other browsers only when the dragging stops and a new window size is set. (this isn't the bug, just a minor difference in the way each browser works)

The bug, is that IE will fire multiple resize events for a single resize of the browser, when Maximizing or Restoring the window.

In IE6, a Maximize or Restore window setting will trigger 3 (three!) resize events.

You can do this by right-clicking the task bar and choosing from the context menu, or by double-clicking the title bar of the browser.

In IE7, they fixed this! Well, not quite. In IE7, it now fires 2 (two!) resize events. Well, I suppose that 1 invalid resize event, is better than 2 invalid resize events, but suffice to say, there is still a significant bug here. This incorrect behavior is still seen in IE8 builds up until IE8 RC1.


Example:

<script>
window.onresize = function(){
  alert('resizing: Offset: ' +
    document.body.offsetWidth + ', ' +
    document.body.offsetHeight +
    '\nScroll: ' +
    document.body.scrollWidth + ', ' +
    document.body.scrollHeight);
};
</script>

Known Workarounds: None. If you need to ensure that a function is called only once for this kind of resize, you may want to store the current width and height dimensions as variables, then onresize, compare them against the stored size. If they are both a match, ignore the event. (e.g. there was no resize)

Related Issues: None.

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 124 - setting innerHTML problem no.1 in IE

Issue: #124
Affects: IE6, IE7, IE8 Beta 1, IE8 Beta 2, IE8 PR1

Setting the .innerHTML in IE can fail in the following scenario.
If you add multiple lines of content (e.g. with line beaks) to an empty element with the overflow set to auto.

Example:

<div id="test" style="border:1px solid #ff0000;height:200px;overflow:auto;">before</div>
<script type="text/javascript">
  var divObj = document.getElementById('test');
  divObj.innerHTML = 'first<br/>second<br/>third';
</script>

You would expect to see the div content update to display:

first
second
third

However IE will update the DOM, but not the content on screen. IE doesn't update the visible height of the DIV, resulting in the "second, and third" not showing.

Known Workarounds: None.

Related Issues: None.

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.