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 493 - no onbeforeunload event in Safari on iPad

Issue: #493
Affects: Safari on iPad

Web Developers have long used the onbeforeunload event to catch users leaving a form partially filled out and prevent them from losing their work. ;-)

On the down side, horribly shady sites have used it to try and keep users on a site with messages about free or cheap offers of electronics or porn if they stay on the site. :-(

It is a great tool when used correctly and thus it is rather unfortunate that Apple has left it off the iPad version of Safari... Users indicate that they have accidentally left a page trying to scroll the view to see better when the keyboard pops up.

Hopefully this will get fixed in a future patch to the OS.

Known Workarounds: None.

Related Issues: None.

Bug/Site Feedback | Submit a bug

bug 552 - no double-click event on the iPad

Issue: #552
Affects: Safari on the iPad

Ok, calling this a bug is a big stretch because it was intentionally removed. This is more of a footnote that the dblclick event is not available in Safari on the iPad.

The reason is that the iPad reserves the double "tap" event to zoom in and out of a Web page.

However there's a few additional events that Safari on the iPad doesn't support (with no obvious reason) but we'll tackle in another post. ;-)

Example:

<script type="text/javascript">
  <div ondblclick="alert('this will never fire');">DBL Click Me</div>
</script>

Known Workarounds: None.

Related Issues: None.

Bug/Site Feedback | Submit a bug

bug 375 - no window.onresize event in IE8 Beta 2

Issue: #375
Affects: IE8 Beta 2, IE8 PR1, IE8 RC1
MSIE Feedback ID: 410707

MSIE Feedback ID: 390166

MSIE Feedback ID: 377719

MSIE Feedback ID: 364571

Note: There was a partial fix in IE8 RC1 however iframes still do not fire resize events properly.

When IE8 Beta 2 shipped it was a significant improvement over Beta 1 - quite simply by the fact that it was actually usable!

There is however a regression bug (that MS claims is fixed in their internal builds moving towards a Q1,2009 RC1 release) with the window.resize event never, ever firing!

As a result, any attempt to capture this event and execute some JavaScript logic on it will fail. Hopefully this will be fixed in the RC release... but we are wondering... does this mean (bug 104) will also be fixed? or will it behave like IE7 did? or IE6 did?

Known Workarounds: None.

Related Issues: One. (bug 104)

Bug/Site Feedback |
Submit a bug

bug 249 - you can't press Tab in IE and capture it

Issue: #249
Affects: IE6, IE7, IE8, IE9, IE10, Safari 4 Beta, Chrome 5,6,7

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

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

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

Example:

Winnings!
$

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

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

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

Related Issues: None.


Bug/Site Feedback |
Submit a bug

bug 149 - no DOM Level 2 Mutation Events in IE

Issue: #149
Affects: IE6, IE7, IE8

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

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

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

Known Workarounds: None.

Related Issues: None.


Bug/Site Feedback |
Submit a bug

bug 279 - onload event for images might not happen

Issue: #279
Affects: IE6, IE7, Opera (ver?)

When you add an image to a page dynamically (via the DOM) and you set the .src attribute, if IE/Opera has it in the cache it is loaded instantly, thus if you set an event handler to catch the onload after setting the source, you're onload event may never fire.

Example:

<script type="text/javascript">
  var myImg = document.getElementsByTagName('img')[0];
  myImg.src = 'highlight.png';
  myImg.onload = function(){
    alert('image loaded!');
  }
</script>

Known Workarounds: One. Move the event handler up to a position before the .src is declared.

Example Workaround Code:

<script type="text/javascript">
  var myImg = document.getElementsByTagName('img')[0];
  myImg.onload = function(){
    alert('image loaded!');
  }
  //define src "after" the onload handler
  myImg.src = 'highlight.png';
</script>

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 229 - not everything is absolute in IE

Issue: #229
Affects: IE6, IE7
Fixed in: IE8 Beta 1

The css "position:absolute" property works well to position a block element in an exact location on screen. However reader Xogede pointed out to us that there are scenarios where IE displays the element correctly, but it doesn't fire events on the element unless the event was triggered on the "text" portion inside the element.

To see this in action, save the code below and open it up in IE6 or IE7. If you click on the text, the onclick event fires and you'll see an alert. If you click anywhere else inside the DIV no event will fire. I've set the cursor to "pointer" so that you can see exactly where the event will fire, but it will turn to the default arrow anywhere that the event firing will fail. Load it up in any other browser and you can click anywhere in the DIV to fire the event.

Example:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
  <title>bug 229 - not everything is absolute in IE</title>
</head>
<body>
<div style="position:absolute;cursor:pointer;top:10px;left:10px;width:200px;border:1px solid black;height:50px;" onclick="alert('Clicked!')">Absolute</div>
</body>
</html>

What is truly odd about this bug, is that it happens in Standards Mode (you know, the one that is supposed to be "closest" to the specs).

The good news is, that this bug can be fixed. All you need to do is specify a background color, e.g. just add this to the DIV's style attribute:
"background-color:#ffffff;"

Known Workarounds: One. Set a background color.

Example Workaround Code:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
  <title>bug 229 - not everything is absolute in IE</title>
</head>
<body>
<div style="position:absolute;cursor:pointer;top:10px;left:10px;width:200px;border:1px solid black;height:50px;background-color:#fffedf;" onclick="alert('Clicked!')">Absolute</div>
</body>
</html>

Related Issues: None.


Bug/Site Feedback |
Submit a bug

bug 263 - beware of DoubleClick in IE

Issue: #263
Affects: IE6, IE7, IE8, IE9 PP1, IE9 PP2, IE9 PP3
Fixed In: IE9 Platform Preview 4 both the extra mousedown and click events now fire!

Satus Update: IE9 Platform Preview 2 shows some improvement and actually does fire the 2nd mousedown event - however it still does not fire the 2nd click event.

Attempting to track events in the process of a doubleclick event in IE will be entertaining to say the least.

The normal sequence of events fired leading up to a doubleclick go as follows.

• mousedown


• mouseup


• click


• mousedown


• mouseup


• click


• doubleclick

but in IE, if you doubleclick on a link, and image or any element, the events fired are:

• mousedown


• mouseup


• click


• mousedown


• mouseup


• click


• doubleclick

Thats right, no second mousedown?, and no second click!
As a developer, if you are tracking mousedown, mouseup, and click events... you need to be aware of this because if your users doubleclick by accident any actions that are designed to "stop" onmouseup might try and reference something that wasn't started... and if the onclick was being used to quit listening for example... that event may never fire.

Example:


Double Click Me To Test!

Event Log

Known Workarounds: None.

Related Issues: None.

Bug/Site Feedback |
Submit a bug

bug 280 - lack of events for options

Issue: #280
Affects: IE5, IE5.5, IE6, IE7, IE8, IE9 PP4, IE9 RC 1, Opera, Safari 3, Safari 4 Beta, Chrome v1, ?
Partially Fixed in: Opera 9.5-9.64 (onclick, onmouseover, onmouseout, onmousedown, onmouseup fixed!)
Partially Fixed in: Safari 4.0 (onclick, onmouseover, onmouseout, onmousedown, onmouseup fixed!)
Partially Fixed in: Chrome 2.0 (onclick, onmouseover, onmouseout, onmousedown, onmouseup fixed!)


The option element is used inside a select element to provide options for the user to select from. Like all visually displayed elements in the browser, you can attach event handlers to them too.

Well, not quite. The following table indicates the level of support for each browser, and event.

Event	Firefox	Internet Explorer	Konqueror	Opera	Safari	Chrome
onclick	Yes	No	?	Yes	No (v4.0 Yes!)	No (v2.0 yes!)
onmouseover	Yes	No	?	No (v9.5 Yes!)	No (v4.0 Yes!)	No (v2.0 yes!)
onmouseout	Yes	No	?	No (v9.5 Yes!)	No (v4.0 Yes!)	No (v2.0 yes!)
onmousedown	Yes	No	?	No (v9.64 Yes!)	No (v4.0 Yes!)	No (v2.0 yes!)
onmouseup	Yes	No	?	No (v9.64 Yes!)	No (v4.0 Yes!)	No (v2.0 yes!)
keyup	No	No	?	No	No	No
keydown	No	No	?	No	No	No
keypress	No	No	?	No	No	No

Only Firefox seems to support the full array of mouse events, Opera is next supporting an onclick event, but in IE and Safari(win) there is no support for mouse events on options.

Oddly enough, no browser seems to support keyboard events on options.

View the following samples in Firefox, Safari or Opera and IE.

Example:


Samples
Red (click)
Blue (mouseover)
Green (mouseout)
Cyan (mousedown)
Teal (mousedup)
No events here
Or here
Orange (keydown)
Yellow (keyup)
Aqua (keypress)

Known Workarounds: None.

Related Issues: bug 291.

bug 193 - onchange does not fire properly on IE radio buttons and checkboxes

Issue: #193
Affects: IE5, IE5.5, IE6, IE7, IE8, IE9 PP4
Fixed in: IE9 RC 1 (in IE9 standards mode only)

The onchange event can be attached (inline or as an event handler) to any form element. It fires whenever the value of the form field changes. Unfortunately, the behavior is a bit strange in IE, in that for a checkbox, or a radio button field, the event doesn't fire when it is supposed to (right when you click the option you want to choose), but instead it only fires, when you click elsewhere on the page/form, or if you explicitly call blur(); on the field.

Example:

<input type="radio" name="foo" value="Green" onchange="alert(this.value);"/>Green<br/>
<input type="radio" name="foo" value="Blue" onchange="alert(this.value);"/>Blue

As soon as you click on either of these radio buttons, the alert should pop up telling you what you just selected.

Try it out!

Green

Blue

You'll notice that it works just fine in all browsers except Internet Explorer. In fact, in IE, clicking once will not pop up the alert, but clicking the other radio button will pop up the alert, but the value is the last radio button clicked.

Known Workarounds: One. Instead of using the onchange event, use the onclick event for radio and checkbox elements instead (or at least for IE)

Example Workaround Code:

<input type="radio" name="foo" value="Green" onclick="alert(this.value);"/>Green<br/>
<input type="radio" name="foo" value="Blue" onclick="alert(this.value);"/>Blue

Test this version with onclick:
Green

Blue

Related Issues: None.

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.