Bug or Feature - Round Six

Round Six Enabling the non-Disabled.

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

We're back again with another round of "Bug or Feature?" 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 today's "Bug or Feature"?

Synopsis:
Everyone knows that form elements [button|input|select|textarea] can be disabled to stop users interacting with them and to ensure they are not "successful controls" when a form is submitted.

So... what happens if you disable non form elements?

In most browsers... Just like you'd expect... absolutely nothing because it isn't supported.

However in IE there is a different behavior.

In IE when you set the disabled flag on an element it "kinda-sorta" disables all the child elements.

Example:

<div disabled="disabled">
  Email:
  <input type="text" name="foo" value="bar"/><br/>
  Send me spam:
  <input type="checkbox" name="baz" value="yes" checked="checked"/><br/>
</div>

So is it expected that the child elements render disabled? What if you wanted one or more of the children enabled?

Known Workarounds: None.

Related Issues: None.



Bug/Site Feedback |
Submit a bug

Microsoft drops support for features in Metro IE 10

Microsoft drops support for features in Metro IE 10 Affects: IE10 Metro Microsoft has dropped support for some legacy IE-only features in IE10 (Metro version) in Windows 8 (due out later this year). Two methods in particular have been dropped: showModalDialog() and showModelessDialog(). Example:

<script type="text/javascript">
 var legacyModalPopup = showModalDialog(url, args, options);
 var legacyModelessPopup = showModelessDialog(url, args, options);
</script>

However that's far from the complete list! Microsoft is also dropping support for common JavaScript features like: MS Pinned Sites, addBehavior, window.print(), window.prompt(), window.open(), window.external, onhashchange event, onoffline event, ononline event, AddSearchProvider(), AddToFavoritesBar(), and yes even window.alert(), window.confirm(), navigator.codeName, and of course there is no ActiveXObject support in IE10 Metro.

Known Workarounds: None.

Related Issues: Too many to count. 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