Web Bug Track

bug 523 - disabling option elements fails in Safari on iOS

2011-09-21T09:30:00.000-07:00

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

2010-11-17T09:12:00.000-08:00

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

2010-09-07T09:17:00.000-07:00

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

2010-07-02T08:15:00.000-07:00

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

2010-06-28T22:14:00.000-07:00

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

2010-06-28T21:26:00.000-07:00

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

2010-06-25T09:53:00.000-07:00

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

2010-06-25T08:41:00.000-07:00

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

Safari on the iPad - The new king of mobile tablet browsers

2010-06-25T08:19:00.000-07:00

Safari on the iPad

The new king?!, says who?! - well the reality is that this is essentially a new market. Oh sure you could get bulky tablet displays that run Windows and IE but that is nothing like the iPad or the soon to be released devices by HP, Google, Microsoft and others.

The trick here is that Apple absolutely "Crushed It!" (thanks Gary Vaynerchuk ;-) when they released their iPad. If you haven't got your hands on one of these devices yet - be sure to stop by your local Apple store and check it out.

This device is so sexy, so portable, yet so simple to use that it changes the game for tablet devices.

It doesn't run a full blown bloated OS, it comes ready to install one of thousands of apps from the AppStore and users are already totally familiar with the interface due to the massive success of the iPhone.

Yeah, yeah, enough of the hype - what about the browser?

Well its no surprise that the browser on the iPad is Safari and it supports a native resolution of 1024 x 768 pixels thus it can render web pages just like its desktop counterpart.

Its a robust browser full of great standards support and even some of that HTML5 goodness that we've all been dying to play with. The good news is that Apple has simultaneously Raised the bar! for the Mobile Web platform. No longer is IE6 the lowest common denominator that you are stuck supporting... you start fresh out of the gate with a very fast standards based WebKit rendering engine based browser - Web Developers rejoice!

So is it all awesome joy and perfect harmony? - well not quite. There are some differences in Safari on the iPad (vs. its desktop cousin) that you'll want to be aware of.

(stay tuned for updates!)
(bug 536)
(bug 543)

Bug/Site Feedback | Submit a bug

bug 511 - checkbox double click fail in IE

2010-06-24T19:43:00.000-07:00

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

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

2010-06-24T19:31:00.000-07:00

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

2010-03-10T09:14:00.000-08:00

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

2010-01-19T08:17:00.000-08:00

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

2010-01-05T08:45:00.000-08:00

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

2009-11-09T09:49:00.000-08:00

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

2009-10-29T07:07:00.000-07:00

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

2009-10-19T15:25:00.000-07:00

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

bug 349 - you cant select a radio button in IE if it doesn't have a name

2009-09-01T18:00:00.000-07:00

Issue: #349
Affects: IE6, IE7, IE8
Fixed In: IE9 Platform Preview 1

This isn't a major bug since it has such a simple workaround but an odd one for sure.

In short it is really simple. If you add a radio button to your page that doesn't have a name attribute, you can't select it... even if it has an id attribute or even if you pair it up with a <label> tag it still won't select.

Example:


<input type="radio" id="foo"/> <label for="foo">Pick Me!</label>
<input type="radio" id="bar"/> <label for="bar">No Pick Me!</label>

Try it out!
Pick Me!
No Pick Me!

If you are using a non-IE browser it should work just fine.

Known Workarounds: One. Add a name attribute and it works just fine in IE.

Related Issues: None.

Bug/Site Feedback |
Submit a bug

Bug or Feature? - Round Five

2009-08-22T17:28:00.001-07:00

Round Five Getting funky with the Cheez whiz!

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

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 the basic form elements [button|fieldset|input|textarea|select]. Within the [input] element there are several types: [button|checkbox|file|hidden|image|password|radio|reset|submit|text].

However there is a quirk/loophole/bug/feature with the <input> element that some browsers are taking advantage of.

By default, if you don't specify the type attribute, or specify a value that isn't recognized as one of the above types the browser should default to "text" (and every browser does) - however some browsers take advantage of certain key types and then render the field in their own special ways.

For example if you use: <input type="search" value="Keywords..."/> in Safari and Chrome it will render like this:

As you can see a little 'x' is provided automatically to allow users to clear the value with a mouse click.

If you don't specify a value Safari will provide a faded tip in the box indicating what the field is for:

Ok, what about other types? and other browsers?

For example if you use: <input type="email"/> in Opera it will render like this:

The little email icon helps identify the field as being a field expecting an email address as the input value and it also increases the default size of ~20 characters to ~25characters (depending on your font selection)

If you use: <input type="url"/> in Opera it will render like this:

Again Opera adds a little icon and increases the field size to ~28 characters.

Know of any other values for type that one or more browsers treat in a special way? If so, let us know!

So now the Question is...

Is this a Bug? Or a Feature?

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

Update: 100 bonus points for Rafael! As noted in the comments below the "url" and "email" types that Opera rendered uniquely just happen to be 2 of the types specified in Web Forms 2.0 and they happened to be 2 of the less decorated fields. The full set of new field types is supported in Opera and they look and work great! We'll post some screen shots of these fields shortly.

Opera's Web Forms 2.0

Date:

DateTime (local):

DateTime:

Time:

Month:

Week:

Number:

Range: (numbers added for visual aid only)

Bug/Site Feedback |
Submit a bug

bug 231 - noscript elements render when script enabled in IE8 Standards Mode

2009-08-17T03:30:00.000-07:00

Issue: #231
Affects: IE8 (Standards Mode), IE9 PP1, IE9 PP2, IE9 PP3, IE9 PP4, IE9 PP6

The <noscript> tag serves 1 basic purpose and that is to provide content when scripting is turned off in the browser.

Years ago the main purpose was to provide alternative content so that your page still worked in browsers without script however these days due to better popup blocking and more interactive content scripting is typically turned on.

Thus the main use of the noscript tag today is to inform the user that JavaScript is turned off and that things won't work until it is turned back on.

[Fake] You need to turn on JavaScript to use the uber cool features on this page. [Fake]

However warnings like this would seem quite out of place when JavaScript is turned on so they are not rendered. Well except that IE8 (Standards Mode) does render the noscript tag container when JavaScript is turned on. This is a regression bug from IE6/7.

Example:

If you are viewing this page in IE8 Standards mode (you'll need to use the IE developer tools [F12] since blogger forces IE7 rendering mode) you will see the outline of noscript tags even when JavaScript is enabled.

Known Workarounds: One. Setting the noscript tag to be display:inline; vs display:block seems to make the container disappear.

Related Issues: None.

Bug/Site Feedback |
Submit a bug

bug 179 - .innerHTML love outside the body is hit and miss

2009-08-12T06:22:00.000-07:00

Issue: #179
Affects: IE6, IE7, IE8, Safari 4, Chrome 2

As most developers know, setting the .innerHTML of an element is one of the fastest ways to dynamically set the content of an element. However there are a few issues when setting the .innerHTML on some elements in some browsers.

For example trying to set the .innerHTML on a [Table, THead, TFoot, TBody, TR] in IE it will fail as will trying to set it on a Select, Pre, or even a (Div with overflow:auto).

Thinking outside the <body> tag, there's a few more tags that you might want to set the .innerHTML on.

The <html>, <head>, <title> tags. Now we can argue that the title tag doesn't accept HTML, but well, we'll let the results speak for themselves.

<html>.innerHTML:
Firefox: Works
Internet Explorer: Fails
Safari: Works
Chrome: Works
Opera: Works

<head>.innerHTML:
Firefox: Works
Internet Explorer: Fails
Safari: Fails
Chrome: Fails
Opera: Works (Partially) resets the title but doesn't update styles or scripts

<title>.innerHTML:
Firefox: Works
Internet Explorer: Fails
Safari: Fails
Chrome: Fails
Opera: Works

Known Workarounds: Use DOM methods to update the content of various tags, and document.title to reset the title value. Just keep in mind that there are other bugs with setting the contents of the script tag, and style tag in IE.

Related Issues: None.

Bug/Site Feedback |
Submit a bug

bug 409 - MooTools redundant getElementById(id) method

2009-08-05T15:48:00.000-07:00

Issue: #409
Affects: MooTools

If you are developing any web sites or web applications these days you are undoubtedly using a JavaScript Framework or have plans to implement one soon.

This bug is about the MooTools framework, specifically about the Element.getElementById() method.

The docs indicate:
Synopsis: Gets the element with the specified id found inside the current Element.
Example: var myChild = $('myParent').getElementById('myChild');
Notes: This method is not provided for Document instances as document.getElementById is provided natively.

Did you spot it? No? Lets run through it bit by bit.

For starters MooTools uses a very simple $('someID') syntax to get an element by its ID.

Combine that with the fact that the ID attribute of HTML elements must be unique within the document according to the W3C specs... and you've now proven that the .getElementById() method on any other element in the DOM is redundant.

E.g. the above example can also be written as (and in much less code I might add):
Example: var myChild = $('myChild');

Now maybe I'm missing something here that is hidden in the docs that helps explain why verbose, redundant code is somehow helpful or that it provides additional features? If so, please comment and let me know!

Known Workarounds: One. Simply don't use it! Its too bad that the API is cluttered with this extra method but it won't cause any harm to use it.

Example Workaround Code:


  var myChild = $('myChild');

When you consider that your JavaScript Framework is providing an API on top of the existing JavaScript/ECMAScript API... you want your Framework API to be as simple and lightweight as possible. Its a minor bug but one that should be addressed to maintain a clean and tight API.

Related Issues: None.

Bug/Site Feedback |
Submit a bug

Taking IE6 out to pasture... one step at a time

2009-07-21T19:12:00.000-07:00

Taking IE6 out to pasture:

If you are a web developer you've struggled with supporting IE6 for quite some time.

Just how long? Browser Life Statuses

Unfortunately dropping support for IE6 isn't that easy when your end users (and paying customers) are using IE6.

Since many people using IE6 don't have a choice (e.g. they are forced to use it at work) the only way to help push users into newer browsers is to move the entire Internet forward.

Once the momentum of sites dropping IE6 support kicks in... I.T. Admins everywhere will feel the pressure to update their end users PCs to a newer version of IE or even other browsers like Chrome, Firefox, Safari or Opera.

To help track which sites are dropping IE support and thus gauge when you should drop IE6 support (if you haven't already) we're compiling a list here.

If you know of a site that is or has dropped IE6 support please let us know!

Dropping IE6 Support:

Site	Status	Notes
37 Signals	Dropping support for IE6	Dropping IE6 support across all products
CrowdSpring	Phasing out IE6 support	Phasing out IE6 support as of March 2009
Digg	Dropping support for logged in actions in IE6 soon	Much Ado About IE6
Facebook	Suggests IE6 users upgrade	...
Get Satisfaction	Dropped IE6 support	...
GMail	IE6 users prompted to upgrade to Chrome	"GMail runs faster in Google Chrome"
iWork	IE6 unsupported	IE6 unsupported, IE7 support is quirky
LinkedIn	IE6 partially supported	The new rich interface features for LinkedIn will NOT work in IE6 by design
Mobile Me	IE6/IE7 unsupported	IE7 unsupported
Mustardseed Media	IE6 support not included by default	IE6 support by default dropped
Projectturf	Dropped IE6 support	IE6 No Longer supported
Scr.im	No interest in fixing IE issues	Won't Fix
Microsoft SharePoint Server 2010	IE6 won't be supported for editing	IE6 won't be supported for editing
Xero	IE6 support dropped	IE6 is no longer supported
YouTube	Dropping support soon	YouTube next to kiss IE6 Support goodbye
Yubby	IE6 unsupported	IE6 is not supported linked image
Google Apps	Google Apps unsupported	support dropping for IE6 March 1,2010
Zenbe	IE6 unsupported	IE6 is not a very standard compliant browser. We almost have to write a different AJAX UI in order to support IE6. Sorry.

Bug/Site Feedback |
Submit a bug

bug 167 - Flash ActionScript communication with IE fails

2009-07-10T19:30:00.000-07:00

Issue: #167
Affects: IE6, IE7, IE8

Adobe's Flash /(SWF) uses ActionScript to interact with the browser and your HTML page. In particular you can call a JavaScript function on your page by using the ExternalInterface Object, using the .call(methodName) method.

However although the code is simple to invoke, you may drive yourself bonkers trying to figure out why it sometimes fails in IE.

Example:


  //required imports
  import flash.external.ExternalInterface;
  //...your code...
  ExternalInterface.call('yourPagesJSFunction');//Fails in IE (sometimes)

So how can this simple code work in Firefox and Safari yet fail in IE?

Known Workarounds: One.

The trick is in the unknown requirement... in IE, your <object> tag REQUIRES an ID attribute! The value doesn't matter, but it must be unique (all your IDs are unique aren't they?)

Example Workaround Code:


<object id="anyvalue">

Related Issues: None.

Bug/Site Feedback |
Submit a bug

bug 444 - IE8 printing issues in standards mode

2009-04-30T19:35:00.000-07:00

Issue: #444
Affects: IE8

MSIE Feedback ID: 431489

IE8 has a new bug with printing. When you change a checkbox or radio button on a page either by clicking it or calling some JavaScript function to toggle it - it looks like it changed but if you try to print it, it won't print in the new state.

In fact it won't even show up correctly in the print preview window!

According to sources at Microsoft there is no intention of fixing this until IE9!

The best part is that this ONLY occurs in Standards Mode. If you render your pages in the Legacy IE7 Mode the checkboxes and radio buttons print (and preview) properly.

Known Workarounds: None.

Related Issues: None.

Bug/Site Feedback |
Submit a bug