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 505 - you can't programatically focus a link in IE unless another link has the focus

Issue: #505
Affects: IE6, IE7, IE8

Here's the scenario: You want to put the current focus on a hyperlink on the page, complete with that dotted border that indicates to the user, that the link has the focus.

Easy enough, right?

Example:

<script type="text/javascript">
  var firstLink = document.getElementsByTagName('a')[0];
  firstLink.focus();
</script>

Well, try it out. In fact, just drop it in the location bar of any other browser as a bookmarklet to verify that it works.

javascript:document.getElementsByTagName('a')[0].focus();

Try the same thing in IE, and you'll notice that the dotted border doesn't show up! Press Tab, and you'll move focus to the next filed, press Shift Tab, and you'll move back, complete with the dotted border. The link does have the focus though... press Enter and you will activate the link.

To see how it should work, press Tab to move between the links on the page. Once you are on a link, complete with the visible dotted border focus, now call .focus() on any other link. Thus it only works in IE, if another link already has the focus, and it was achieved manually.

Known Workarounds: None.

Related Issues: None.


Bug/Site Feedback |
Submit a bug

bug 173 - form field focus issues in Safari

Issue: #173
Affects: Safari 3.1 (Win), {Safari 3.1 (Mac)?}

As more and more applications go online in this Web 2.0 world, interactions with forms are critical to an applications success. Safari leads the way with built-in textarea resizing but it has a major issue with form field focus.

Since data entry in forms is a crucial part of online forms, ensuring that your forms are both keyboard and mouse navigable is important. Unfortunately in Safari the keyboard navigation breaks if you use the mouse on radio or checkbox elements. This becomes a major issue because although radio and checkbox elements are keyboard accessible, in general users prefer to use the mouse to make their selection(s).

The issue is this. If you use the mouse to select a radio or checkbox field one expects that that field has the focus and thus a 'Tab' will take you to the next available field (or whatever is defined in the tabindex order). When the user presses 'Tab' in Safari, the focus resets to the first form field on the page!

If you use the mouse for other types of fields, or use only the keyboard the issue doesn't occur.

Example: (Try it out!)

First Name:
Last Name:
Email:
Life Story:
Gender:
Female
Male
Pets Name:
Spam Preferences:
Pornography (NSFW collection)
Medications (weight loss, ED, muscles)
Mortgage/Loan (impossible rates)
Religion (guilt, pressure, overtones)
Fakes (fake rolex, cartier, artwork)
Hot Stocks (buy! buy! insider info)
Pirated software (OEM, Bulk, Download)
Illegal Music/Movies (Torrents, P2P)
Surprise Me! (Scams, popup, virus)
Address Line 1:
Address Line 2:
Comments:

Known Workarounds: None.

Related Issues: (bug 132).

Bug/Site Feedback |
Submit a bug