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