Microsoft reverts their decision to block Flash by default in IE10!

Microsoft reverts their decision to block Flash by default in IE10 - Users and Developers rejoice!

If you've been following along you'll know that Microsoft announced back on September 2011  that IE10 running in what they used to call "Metro Mode" would no longer be running addons including Adobe Flash.

This generated a lot of controversy when announced because IE & Windows supported a lot of legacy websites & applications that depended on Flash.

Even in January 2012 they were still determined to do this (again even with developers complaining)

Again in April 2012 they continued with their mission.

Then they came to their senses in June 2012 and opened up Flash access after working with Adobe to optimize it for better CPU/battery use.

However they still didn't have it right.

They forced developers to go through a painful analysis, testing & registration process in order to request permission to have their site added to a special list (the CV whitelist) that granted permission for the site to run flash.

• They required developers to test on hardware that wasn't commercially available
• They ruined the user experience by taking control away from the user.
• The user would visit a site and the content would be blocked - yet they had no way to know nor any way to enable it if they wanted.

• They used a whitelist instead of a blacklist (classic programming flaw when dealing with billions of anything)

Now in March 2013 they finally addressed the fact that this design decision was a bad one and have reverted their settings so that Flash is actually enabled by default.

Everyone wins!

Users will be able to see/use/interact with the content they intended to view and for the few sites that have issues they've been added to a blacklist (instead of a whitelist) so that they can be better controlled.

A lot can happen in a year and a half! Thankfully Microsoft did the right thing in the end - even if they made Web Developers loose countless nights of sleep in the process.

bug 345 - keyboard locks up in iOS WebKit textarea

Issue: #345
Affects: iOS WebKit 536.26 (Safari & Chrome on iPhone, iPad, & iPod)

Note: this issue is specific to iOS.  WebKit running on BlackBerry / Android devices are unaffected by this bug.

Under normal circumstances a TextArea (even in WebKit) works just fine however on iOS6 and WebKit 536.26 there is a bug with textareas if they are within an iframe.


Example:

<iframe src="somePage.html"></iframe>

and then in somePage.html

<textarea cols="60" rows="6">

type a bunch of multi-line content (e.g. "abc" [Enter] over and over)

</textarea>

Yup! that's all the code you need... a textarea in an iframe (very common in today's inline overlay popups).

Just type multiple lines of text (enough to be able to scroll the textarea vertically).

Then re-position the cursor elsewhere in the textarea and try to type again... Denied! The keyboard is almost useless as no characters will render on screen (oddly enough the backspace/delete key still works fine!)

Frustrating isn't it! Gah!

Known Workarounds: One. It isn't obvious but if you dismiss the keyboard or use Previous/Next to jump to another field and come back to the field everything works again!

Related Issues: None.

If you have a SmartPhone or Tablet that runs a WebKit browser (basically any of them except Opera, Firefox (or a Windows 8 tablet)) please try this out and see if we can narrow down the specific versions/Operating Systems affected.


Bug/Site Feedback | Submit a bug

bug 571 - IE 10 Textarea focus is broken (Breaks Fitts's Law)

Issue: #571
Affects: IE10 (Windows 7) (Might affect Windows 8)

Microsoft released IE10 RTM for Windows 7 on February 26th exactly 4 whole months after it was released for Windows 8.

While this was a welcome upgrade for the developer community it was met with a lack-luster response.

The UI skin was directly ported from Windows 8 and so every control is rendered flat, no longer responds to the hover event visually and has lost all the visual styling and clues that made Windows 7 such a successful operating system.

2 significant issues have come out of this (1 is related to select lists (but that will be coming in a future post)) but the other is a behavior regression in the Textarea Element.

In normal use a user can place the cursor at the end of any line of text by clicking in the textarea anywhere to the right of that line.  This enables easy navigation within the textarea to jump in at any point and start editing.

In IE10 it does work but only in very specific circumstances.

The bug exhibits itself currently in any Textarea where the field is defined but no line break appears in the content of the tag. e.g. an empty Textarea (the default for most textarea's initially). Instead of putting the focus at the end of the line IE 10 places it at the beginning of the next line unless you click within a pixel or two of the last character.

If any developers can test this in IE10 on Windows 8 (both Desktop and Metro) please let us know if the issue exists there too.

Example:

This Fails:

<textarea cols="60" rows="8">Add Lines and try to navigate!</textarea>

Yet this works fine:

<textarea cols="60" rows="8">

One
Two
Three

</textarea>

We hope that Microsoft can fix this quickly and thus can get this patched up before Automatic Updates kick in for Windows users.  Currently this regression is annoying and is a direct violation of Fitts's Law.

Known Workarounds: None. Well you could add line breaks to every textarea in your sites/apps but this is something that Microsoft should fix ASAP not Web Developers.

Related Issues: None.

Bug/Site Feedback | Submit a bug

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 503 - window.prompt() no longer supported in IE10 "Metro"

Issue: #503
Affects: IE10 "Metro" on Windows 8

Note this bug affects "Metro" (and we need to use air quotes because Microsoft has not clarified what this new OS mode will be called after Metro AG staked their legal claim to the copyright name).

One of the many changes in IE10 "Metro" is that not only do plugins no longer work (with the exception of a minor chance of running Adobe Flash) but some basic functionality has been removed.

In IE10 Metro the window.prompt(msg, default); method no longer works - period. 


Example:

<script type="text/javascript">
  var username = prompt('What is your name?','');

  alert('Your username is: ' + username); 

</script>

In all browsers this will alert the username that the user enters however now in IE10 "Metro" this method is technically defined however it will never show the prompt and will return undefined.

We find it humorous that after supporting the method badly for over a decade Microsoft chose to drop the method completely rather than fix the bugs  bug 109, bug 139!

When Microsoft was questioned about this change on MSDN and the IE Blog Microsoft chose not to comment. In fact Microsoft has been pretty quiet in general since committing to  the final RTM builds of Windows 8 (and thus IE10) not responding to any of the direct questions from developers. Read into that what you will, but we find it very unsettling... lack of communication is never a good thing.

Known Workarounds: None.

Related Issues: bug 109, bug 139
 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 517 - Internet Explorer Zoom doesn't always work

Issue: #517
Affects: IE7, IE8, IE9, IE10 Preview

Ever since Internet Explorer supported zooming page content in the browser there have been issues with the Zoom feature.

In IE7 it was rough and it was particularly bad scaling form elements unequally not to mention framesets were a disaster.  In IE8 things got much better and the scaling was much more predictable.

However there are 4 issues with Zoom in IE to this day that drive developers and users alike bonkers.

1.) The default keyboard shortcut of [CTRL] + [0], [CTRL] + [-], and [CTRL] + [+]  to adjust the zoom do NOT work if you use the numberpad keys.

2.) The zoom isn't a graceful increase when zooming in 5% at a time like in other browsers.  IE's first "step" is a whopping 125%!  As developers this isn't always easy to accommodate gracefully... many users just want to bump up the zoom a "notch" and 125% is overkill.

3.) The performance of a web page drastically decreases when zoomed in to the point that on heavy web pages the site becomes almost unusable - Most corporate web applications do not support use of Zoom in IE as a result.

4.) Zoom isn't applied to everything! Oh sure, you probably knew that radio buttons don't scale but did you know that if you have any dialog windows created using Microsoft's proprietary showModalDialog() or showModelessDialog() methods that the content inside them completely ignores the users request to have the content zoomed.

Does your site/application support the Zoom feature in IE? Have you seen how it behaves compared to other browsers?

Note: The Modal, and Modeless dialogs in Internet Explorer have been deprecated in IE10 Metro Mode thus if you were still using them for some strange reason it is time to update your code!

 

Known Workarounds: None.

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