bug 519 - IE8 InPrivate/Windows Media Player Fail - OS integration issues

Issue: #519
Affects: IE8 (IE6, IE7 also fail the basic privacy issue disclosed below)

So, you think that IE8's InPrivate will cover your tracks when you surf... *cough*, *cough* questionable video content on the Internet?

Think again! do you remember a battle between the D.O.J. (Department Of Justice) and Microsoft over Internet Explorer being "part" of the Operating System and therefore they couldn't remove it to make a even playing field for other Web Browsers?

Well IE is tied to the OS... even if you aren't using IE! because the IE "favorites" and "history" are tied to the OS (not just IE).

So if you went and downloaded/watched some videos in say... Firefox... that opened up in Windows Media Player.

Then in Firefox you clicked the "Clear Private Data" link to remove all traces in Firefox.

Now open IE... and view IE8's History... what on earth?! the videos you watched from Firefox/Windows Media Player now show up in your IE History!

So who gets credit for the bug? Is it Firefox? likely not because it erased all data it stored. So its between Windows Media Player and IE8. In Windows Media Player's options... Privacy Tab... the History checkbox is unchecked - therefore requesting that URL/file history NOT be saved.

So where is the bug? Is Windows Media Player storing history when you told it not to? or is Internet Explorer tracking its own copy of your OS history without consent? or is Windows itself somehow to blame?

Either way Microsoft has a bug to fix. No history means No history.

It should be noted that surfing in IE8's InPrivate, downloading videos, and closing the InPrivate session does seem to clear the history.

Note: This bug was discovered on Windows XP SP3, IE8 RC1 and Windows Media Player 10. (it may not occur in other setups)
Update: This bug affects all versions of IE and Windows (Windows7/IE8 combo not tested yet - please send in a comment if you can confirm that this bug still exists/does not still exist in Windows 7)

Known Workarounds: None.

Related Issues: None.


Bug/Site Feedback |
Submit a bug

bug 318 - press any key to... crash Safari

Issue: #318
Affects: Safari 3.1, 4.0 Beta
Fixed In: Safari 5.0

In testing (bug 487) we found that Safari consistently became unstable and crashed if you tried to modify the options of a select list while the select list was open by using the onkeydown or onkeypress event (onkeyup won't crash (but doesn't work either)).

A test case is provided below, but be warned, this will crash Safari! so be sure you don't have anything in another tab that you need to save.

(and for the record, this bug/crash report has been sent to Safari)

Try the following sample out, and come back soon! ;-)

Example: (open the list, and "Press Any Key")
OnKeyDown Test:
100
200
300
400
500
600



Example: (open the list, and "Press Any Key")
OnKeyPress Test:
100
200
300
400
500
600

Known Workarounds: None.

Related Issues: (bug 280), (bug 487).


Bug/Site Feedback |
Submit a bug

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

Fixed bugs in IE8

Fixed bugs in IE8:

We've started to aggressively mark those bugs that are fixed in IE8 as such. The final version of IE8 has yet to be released but there is a presumption that a bug that is fixed in IE8 RC1 will remain fixed for the IE8 RTM release.

However there is a significant catch. When Microsoft fixed most of these bugs, they only fixed them in the "IE8 Standards Mode" which is the new mode that IE renders content in its "best possible, most standards way that it can".

This means that in order to see any of these fixes work, you MUST generate your pages with a valid doctype and the page MUST be somewhere on the Internet, not the Intranet (A point most developers argued against but Microsoft stood firm).

That all said, bugs marked with the "Fixed" tag are bugs that from preliminary testing appear to be working fine in IE8 in IE8 Standards Mode.

With deep regret (ours) there are also bugs that Microsoft has indicated will not be fixed in IE8 RTM, and those have been marked with the "Broken By Design" tag.

IE8 RTM is on the horizon now and the IE Team has indicated that there will not be any more public IE releases before the final (we hope that means there will be another private release, but we aren't getting our hopes up).

If/When time permits, we'll publish a complete list right here so that there is a quick list to check against. Thanks for all the input and bug submissions (for any browser of course) and feedback.

[List will go here]
Fixed:
(bug 101) - buttons render stretched and distorted in IE (WinXP)

(bug 152) - getElementById returns incorrect objects in IE and Opera

(bug 154) - getElementById is NOT case sensitive in IE

(bug 163) - no valign in table cells in IE8

(bug 165) - dynamic pre population fails in IE

(bug 184) - The catch to Try Catch Finally in IE

(bug 190) - fieldsets are broken in IE8

(bug 215) - no hasAttributes() support in IE6, IE7

(bug 217) - getAttribute doesn't always work in IE

(bug 229) - not everything is absolute in IE

(bug 268) - hasAttributes not supported in IE

(bug 293) - can't disable options in IE

(bug 299) - setAttribute "checked" does not work in IE

(bug 329) - Element.setAttribute('style', '...') fails in IE8 Beta 1

(bug 333) - microsoft drops all support for opacity in IE8!

(bug 341) - the button element submits the wrong value in IE

(bug 347) - IE8 Beta 1 - text highlighting background issue

(bug 371) - named anchor links are broken in IE8

(bug 471) - font-weight:600 stretches text in IE



Broken By Design:
Status: Microsoft has confirmed that these bugs will NOT be fixed in IE8 RTM
(bug 109) - JavaScript prompt() in IE - How did this not get fixed in IE7?!

(bug 126) - no W3C DOM Level 2 Event Listeners

(bug 132) - slow checking checkboxes required in IE

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

(bug 237) - type is a readonly attribute in IE

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

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

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

(bug 411) - getElementsByName doesn't work in IE

(bug 421) - IE fails to pass the HTTP Referer on many navigations

Bug/Site Feedback |
Submit a bug