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 or Feature? - Round Two

Round Two - Safari changes your styles did you know?

Other rounds: [One|Two|Three|Four|Five]

We're back again with another round of "Bug or Feature?" (see round one) highlighting a particular behavior in one or more browsers, that, well, could be a Bug, or it could be a Feature... we'll open up the comments for your vote and opinion.

Alright, what's todays "Bug or Feature"?

Synopsis:
In Safari, usability of textarea elements has been greatly improved by allowing the user to decide how wide and how tall it should be, by making a grippy that the user can drag to stretch. Its a great feature, that many other browsers are looking into (Ask ASA, it's on his top 10 for Mozilla Firefox).

What is interesting, is that as a developer, if you ask for the .innerHTML of an element that wraps a textarea in JavaScript, it will report back exactly what you supplied... *except* if the user changed the dimensions of the textarea, the style attribute is now filled with margins, paddings, width and height values that you didn't specify.

If I have the following HTML, I would expect it to return the same content:

Example HTML snippet:

<div>
<textarea name="a_textarea" cols="40" rows="4">
  Hello World
</textarea>
</div>

Expected [div].innerHTML returned:

<textarea name="a_textarea" cols="40" rows="4">
  Hello World
</textarea>

Question:

If the user stretches the textarea in Safari (or later in other browsers), and you asked for the .innerHTML and got something different than the HTML fragment above...

Try it yourself.

(ignore the br tag in the alert (blogger auto-inserts this)

Is this a Bug? Or a Feature?

Vote "Bug" or "Feature", and add your thoughts.