Site Navigation

Wednesday, September 21, 2011

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

Wednesday, November 17, 2010

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

Tuesday, September 7, 2010

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

Friday, July 2, 2010

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

Monday, June 28, 2010

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

Friday, June 25, 2010

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