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 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

bug 523 - disabling option elements fails in Safari on iOS

Issue: #523 Affects: Safari on iOS (iPod, iPhone, iPad) Select options support a disabled attribute so that developers can optionally disable individual options if/when they are not applicable. Safari on the desktop (Windows or Mac) both support this attribute however Safari on iOS (so iPod, iPhone, & iPad) the attribute doesn't actually do anything and the user is free to select the option even though it is supposed to be disabled. Example:

<select>
  <option value="1">first<option>
  <option value="2">second<option>
  <option value="3" disabled="disabled">third<option>
  <option value="4">forth<option>
</select>

If this select list were rendered on an iPhone or iPad you would be able to select the "thrid" option. It's not a Webkit bug, since the same select list will render perfectly on other tablets like the BlackBerry PlayBook.

Known Workarounds: Two. You'll need to either need to remove the options, or inform the user after their selection that it isn't valid (not recommended for usability purposes)

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

bug 196 - IE9 fixes almost .setAttribute('type', value);

Issue: #196
Affects: IE9 PP4, IE9 Beta, IE9 Platform Preview 6

We're happy to say that IE9 has brought many, many improvements to Internet Explorer in terms of updating the IE engine to properly handle standards based code.

IE had issues in the past with the Element.setAttribute(name, value); method for a long time not supporting it on a wide array of elements (bug 242) of which the type attribute was a significant one (bug 237).

We were hoping that after IE9 Platform Preview 4 was released and we found that the .setAttribute('type', value); method had finally been fixed that the "new" bug with the value being erased when switching an HTMLInputElement from type "password" to "text" would have been fixed 2 public releases later.

Unfortunately it is still broken and thus we're tracking this new issue separately here.

Example:

<input type="password" id="accessCode" name="accessCode" value="bfg10k"/>
<script type="text/javascript">
  function exposeCode(){
    var field = document.getElementById('accessCode');
    field.setAttribute('type', 'text');
    //Oopsie! the value is now gone in IE9!
  }
</script>

Known Workarounds: None.

Related Issues: None.

Bug/Site Feedback | Submit a bug

bug 387 - setAttribute('type','file'); fails in Chrome & Safari

Issue: #387
Affects: IE6, IE7, IE8, IE9 Beta, Chrome 5,6,7, Safari 5
Fixed In: IE9 Platform Preview 6 (only when rendering in IE9 Standards Document Mode)

We've long known that IE has problems with both setAttribute (bug 242), and specifically changing the type attribute (bug 237) however it looks like it is Chrome and Safari that have an issue now.

It seems that in Chrome and Safari you can't set an input element's type attribute to "file". Try it out below! (It will fail in IE too of course, but that's a known issue)

Example:
filename:

Known Workarounds: None.

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

bug 493 - no onbeforeunload event in Safari on iPad

Issue: #493
Affects: Safari on iPad

Web Developers have long used the onbeforeunload event to catch users leaving a form partially filled out and prevent them from losing their work. ;-)

On the down side, horribly shady sites have used it to try and keep users on a site with messages about free or cheap offers of electronics or porn if they stay on the site. :-(

It is a great tool when used correctly and thus it is rather unfortunate that Apple has left it off the iPad version of Safari... Users indicate that they have accidentally left a page trying to scroll the view to see better when the keyboard pops up.

Hopefully this will get fixed in a future patch to the OS.

Known Workarounds: None.

Related Issues: None.

Bug/Site Feedback | Submit a bug

bug 391 - IE is strict in setting innerHTML but not appendChild

Issue: #391
Affects: IE6, IE7, IE8, IE9 PP3

IE is well known historically as a browser that doesn't follow the strictness of standards well. IE will often let you do things that you shouldn't be able to do (e.g. add a div to a select element)

However there are cases where IE is very picky - although confusingly arbitrary in how and when it decides to be strict.

Take for example the <p> element. By definition, this is an inline element which means it should not contain block elements.

The following however seems to work fine in all browsers (e.g. the "rule" isn't strictly enforced")

Example:

<script type="text/javascript">
  var newHeading = document.createElement('h1');
  newHeading.appendChild(document.createTextNode('I am an H1 element!'));
  myParagraph.appendChild(newHeading);
</script>

However in IE, if you change this to use .innerHTML to set the value IE throws an error.

Example:

<script type="text/javascript">
  var newString = '<h1>I am an H1 element!</h1>';
  try {
    myParagraph.innerHTML = newString;
  } catch(ex){
    alert('Failed: ' + ex['message']);
  }
</script>

Which IE then throws an error with the very helpful "Unknown runtime error" message.

This is repeatable for any block level elements: div, h1, h2, h3, h4, h5, h6, blockquote etc.

This obviously isn't desired markup thus the issue with the error is minor however it could well crop up when you adding either content you are not intimately familiar with (JSON response?) or you know the content but are not aware the container element you plan to drop it into is actually an inline element.

Keep this in mind the next time you encounter an "Unknown runtime error" as it might turn out to be a "known issue" ;-)

Known Workarounds: Two. Either ensure you never try to set the innerHTML of an inline element to a block element or use the appendChild() method instead.

Related Issues: None.

Bug/Site Feedback | Submit a bug

bug 552 - no double-click event on the iPad

Issue: #552
Affects: Safari on the iPad

Ok, calling this a bug is a big stretch because it was intentionally removed. This is more of a footnote that the dblclick event is not available in Safari on the iPad.

The reason is that the iPad reserves the double "tap" event to zoom in and out of a Web page.

However there's a few additional events that Safari on the iPad doesn't support (with no obvious reason) but we'll tackle in another post. ;-)

Example:

<script type="text/javascript">
  <div ondblclick="alert('this will never fire');">DBL Click Me</div>
</script>

Known Workarounds: None.

Related Issues: None.

Bug/Site Feedback | Submit a bug

bug 543 - no window.print() in Safari on the iPad

Issue: #543
Affects: Safari on the iPad

Printing web pages is very common when you just want to be able to hold something physically in your hands or take home with you after work to read when you have time.

With Safari on the iPad - there isn't a print option, and likewise there is no

window.print();

method implementation in the iPad version of Safari.

With any luck this won't be an issue for most users as they can surf and read the online content wherever they want... but if you were hoping to scribble notes, correct content or go to town with your rainbow array of highlighters you are out of luck.

Known Workarounds: None.

Related Issues: None.

Bug/Site Feedback | Submit a bug

bug 536 - no file upload in Safari on the iPad

Issue: #536
Affects: Safari on the iPad

The iPad is great for everyday web surfing on the couch or on your daily commute but Safari on the iPad has some quirks that make it significantly different than the desktop version.

For starters - the HTML <input type="file"/> element doesn't work. It renders as a disabled input. So if you were hoping to send pictures or MP3's by attaching them to an email in GMail or Hotmail etc. you are out of luck.

Since the iPad doesn't really expose an operating system and files to the user - this does kind of make sense - though I'm sure it will confuse some users at first.

Known Workarounds: One. When viewing your pictures directly on the iPad - choose the option in the top right to "send" the picture to an email address. You are limited to 1 picture at a time, and the To: field won't remember the email address for you :-( but it will work.

Related Issues: None.

Bug/Site Feedback | Submit a bug

bug 511 - checkbox double click fail in IE

Issue: #511
Affects: IE6, IE7, IE8, IE9, IE10

On the web almost all interaction is based on the single-click concept. You click once to follow a link, you click once to press a button, once to open a dropdown select list, select a radio button or checkbox element etc.

So if you were to double click an element that toggles (e.g. like a checkbox) you would expect the first click to change it from state A to state B... and the second to change it from state B back to state A. (e.g. unchecked - checked - unchecked)

This works as expected in all browsers except IE. In IE double-clicking a checkbox will only switch the state once from A to B.

Example:

Try Double Clicking these options:

Apple
Linux
Microsoft
HP
Dell
Cisco


Realistically this isn't a major issue as most users are unlikely to double click a checkbox... however based on the number of post on web forums and newsgroups about how to stop users from double clicking and re-submitting data - it certainly does happen.

Known Workarounds: None.

Related Issues: (bug 132) (bug 193).

Bug/Site Feedback | Submit a bug

bug 419 - fieldset legends broken again in IE9 PP3

Issue: #419
Affects: IE9 PP3, Opera 11
Fixed In: IE9 Platform Preview 6

Update: Opera latest release (version 11) is also showing broken fieldset legends.

It appears that the latest IE9 Platform Preview #3 (PP3) has re-broken (bug 190) the fieldset element to cause rendering glitches with the legend element.

Example:

Communication preferences:

Please use the following methods to contact me;
Email
ICQ
MSN Messenger
Yahoo! Messenger
Google Talk
Phone
Fax
Skype

As you can see, (if you use IE9 PP3) the legend does not render correctly at all. The legend is not contained inline within the fieldset border. Hopefully this is just a bug in this third preview.

Known Workarounds: None.

Related Issues: (bug 190).

Bug/Site Feedback | Submit a bug

bug 358 - saving web pages is incredibly slow in IE

Issue: #358
Affects: IE6, IE7, IE8

Rendering content in the browser is obviously the main goal of day to day web surfing and web application usage.

There's form interaction, games, Facebook, Mashups & Twitter updates just to name a few.

However when you get a bunch of info/data you care about you likely want to do something with it. Typically you'll want to print, save or export your content so that you have a hard copy or backup.

However exporting is only an option if the web application you are using supports that feature... and printing is a great way to waste trees... but a 500 "page" report is something better suited to be saved to a digital file. Besides maybe you want to manipulate that data in your spreadsheet program before printing it or making a PDF to share.

Alright, easy as pie... just render the page you want and choose Save as from the right click menu file menu.

Should take about a fraction of a second to save the page you are viewing (already downloaded) to an HTML file.

Well not quite! Although Firefox, Chrome, Opera & Safari all do this in milliseconds IE does not. Internet Explorer re-requests the ENTIRE file from scratch. Yes, that's right, re-downloads an EXACT DUPLICATE of your (example) 500 page report!

Needless to say this is a massive waste of bandwidth and user time as they wait for the page to be re-fetched... while staring at the already rendered copy they already have!

Known Workarounds: None. Well I suppose the more technically inclined could view the source... then CTRL+A (select all), then CTRL+C (copy), then CTRL+V (paste) and save in your text editing application of choice - but that seems awfully inconvenient when there is a save as option in the file menu.

Related Issues: None.



Bug/Site Feedback |
Submit a bug

bug 209 - prompt() rendering glitch in Opera

Issue: #209
Affects: Opera 10.10, 10.20, 10.50, 10.60

Unlike the problems with the prompt dialog in IE (bug 109) (bug 139), and the features of the Safari prompt dialog (feature 266), the Opera JavaScript dialogs have typically been excellent and even lead the pack in terms of features like adding the hostname to help prevent XSS (Cross Site Scripting) and a checkbox to escape endless loops that crop up mostly during development of course! ;-)

However during some dialog testing we noticed that Opera has a rendering glitch with the prompt() dialog.



Example:

<script type="text/javascript">
  var data = [];
  var count = 50;
  for(var i=0;i<count;i++){
    data.push('For your information, this is item # ' + (i+1));
  }
  prompt(data.join('\n'),'a default value');
</script>

Known Workarounds: None. You'll have to limit your prompt dialogs to a few paragraphs. (Keep in mind that IE can't render more than 2 lines!)

Related Issues: None.


Bug/Site Feedback |
Submit a bug

bug 396 - more style tag limits in IE

Issue: #396
Affects: IE6, IE7, IE8

Microsoft Support KB: 262161

You may already be aware that Internet Explorer has some limitations with the amount of CSS it can handle (bug 327) so that you can only load a CSS file up to ~288kb in size and the total number of CSS selectors/style rules can't exceed 4096 but there's more!

IE will also only allow you to have a maximum of 30 style tags on a page! So if you have a site that injects a lot of style tags on the fly for components/widgets you may want to think twice about this approach.

Run this code in IE and note that IE caps out at 30 and doesn't create the addition 70 stylesheet tags.


Example:
(note: this is IE specific code)

<html>
<head>
<script type="text/javascript">
function createStyleSheets(){
  for(i=0;i<100;i++){
    document.createStyleSheet();
    var msg = 'Total Style Sheets = [<b>' + i + '</b>] of 100.';
    document.getElementById('ssCount').innerHTML = msg;
  }
}
</script>
</head>
<body onload="createStyleSheets();">
  <div id="ssCount"></div>
</body>
</html>

How many style tags do you have on your page? Add this bookmarklet to your browser and find out. (note if you run it in IE and it says 30, you may well have hit the limit!)

# style tags

Known Workarounds: None.

Related Issues: (bug 327).


Bug/Site Feedback |
Submit a bug

bug 225 - no support for TBody CSS height or overflow in IE in Quirks or Standards mode

Issue: #225
Affects: IE6, IE7, IE8

The beauty of CSS is that you can take a simple design and enhance it with a style sheet for aesthetics and usability.

A classic enhancement is to wrap table rows in a tbody element that will allow for vertical scrolling when they exceed a certain height.

All you need to do is set 2 or 3 CSS properties.

Example:

<style type="text/css">
  tbody{
    height:100px;
    overflow-x:hidden;
    overflow-y:auto;
  }
</style>

This works great and thus makes the table headers always visible even when the user has scrolled to the bottom of the table.

However in IE there is a catch. If you don't have a DOCTYPE set and thus are rendering in Quirks Mode - IE decides that your tbody height isn't for the entire table contents but instead should be applied to every single row in your table! In fact IE6 & IE7 do the same thing in Standards Mode too. Only IE8 running in IE8 Standards Mode doesn't alter the TR row height.

Sample screenshot from Firefox:


Sample screenshot from IE8 in Quirks Mode (same result for IE6 and IE7 in Standards Mode):


Sample screenshot from IE8 in Standards Mode:


I'm not entirely sure how or why this implementation would have ever made it past an initial code check-in as it is obviously wrong, serves no useful purpose, and I fail to see how this could possibly be helpful to any developer or end user.

Of course this is really just one stumbling block on the way to another. Even if you do render in Standards Mode - IE still won't render the vertical scrollbar on your tbody nor restrict the height and thus you still can't improve the user experience for IE users.

If you do have a simple technique to make scrollable tables work in IE - please submit feedback indicating how. Outside of very complex hacks I haven't seen any that work in IE.

Known Workarounds: None. IE does not support CSS height, overflow, overflow-x, or overflow-y on a TBody element.

Related Issues: None.


Bug/Site Feedback |
Submit a bug

bug 361 - Anchors collection in IE contains invalid members

Issue: #361
Affects: IE6, IE7, IE8

In the days before the DOM Methods we have today we only had access to a few special collections for things like forms, anchors, links, images, etc.

They may not be as sexy as document.getElementById(), but they worked, and still do to this day... and depending what you are trying to access may actually be much quicker and easier.

So to the point, the document.anchors collection contains an array of all the anchors defined in the page.

Anchors by definition are <a> tags with a name attribute specified.

Now for the bug.

As disclosed in (bug 152) IE has notoriously had issues with differentiating between id and name attributes, polluting IDs with NAMEs and vica versa.

Thus, if you have hyperlinks with an id attribute set in IE... you will now have a new member in the document.anchors collection even though there is no name attribute specified! Have lots of links with id attributes set? Then you have lots of extra items in your document.anchors collection.

Of course the interesting twist on this is that in modern browsers, any element (div, table, span, img) with an id attribute set can act "like" an anchor in that you can add it as a hash tag in the URL to auto-scroll to a specific spot however keep in mind that by definition only an <a> tag with a name attribute set is a valid element in the document.anchors collection.

Known Workarounds: None.

Related Issues: None.


Bug/Site Feedback |
Submit a bug

bug 234 - showModalDialog Array returnValue now fails

Issue: #234
Affects: IE6, IE7, IE8

We haven't discovered if this bug is exclusive to VBScript or if it affects JavaScript too (but feel free to update us in the comments if you know).

If you downloaded the latest IE Cumulative Security Update for October 2009 security patch, which "fixed" Microsoft Knowledge Base Article 974455 then you may have noticed that the showModalDialog documentation indicates that the window.returnValue accepts an Array.

However after updating KB974455, there was an undocumented change that now Array return values are no longer allowed.

So what can you do if you depend on this non-standard dialog? Well, the workaround is ugly but there hasn't been confirmation from Microsoft that this bug was introduced - nor that a fix is on the way.

Known Workarounds: One. Use something other than an Array and handle the return value accordingly.

Example Workaround Code:

On the Popup window:

<script type="text/vbscript">
  //was
  window.returnValue = arrayValue;

  //now use
  arrString = Join(arrayValue, ";");
  window.returnValue = arrString;
</script>

On the Calling window (e.g. Opener):

<script type="text/vbscript">
  //was
  retArray = window.showModalDialog( ... );

  //now use
  tempRetArray = window.showModalDialog( ... );
  retArray = Split(tempRetArray, ";");
</script>

Related Issues: None.



Bug/Site Feedback |
Submit a bug