Opera

Opera:

Opera is an interesting browser, that was first on the scene for many advanced features in the browser (tabs, zooming, security), but didn't gain a lot of traction because it was distributed on a "shareware"-like model when competing directly against IE. It's since been offered for free (since Firefox became very popular), and has had a significant increase in users.

Pros:
Its fast, blazing fast!
Has every feature you'll ever need
Follows most spec items very well

Cons:
Has a legacy of mimicking IE, including many of IE's bugs
Doesn't allow [Tab] navigation of hyperlinks :-(


Bugs: (bug 152)

More to come...

bug 101 - buttons render stretched and distorted in IE (WinXP)

Issue: #101
Affects: IE6, IE7 (on WinXP)
Fixed in: IE8 Beta 1

On Windows XP in IE6 or IE7, with the default themes applied the input button element renders stretched and distorted when the length of the value exceeds 17 characters.

In fact, the padding on the button also changes, depending on the length of the value attribute, which is also a buggy.

Example:

<input type="button" name="test" value="Distorted in IE on XP" onclick="alert('How do I look?');"/>

View this page in Windows XP in IE6 or IE7 to see the rendering bugs.










You don't even have to use Windows XP to see the padding expansion bug. IE6 on Windows2000 or Windows2003 will also display the issue.

Known Workarounds: CSS Hacks.

Example Workaround Code:

{soon}

Related Issues: None.

bug 217 - getAttribute doesn't always work in IE

Issue: #217
Affects: IE5, IE5.5, IE6, IE7, IE8 Beta 1, IE8 Beta2, IE8 PR1
Fixed In: IE8 RC 1

Certain attributes can not be retrieved properly in IE. The first example, is the "for" attribute, which is used by <label> tags to link to input fields.

Example:

<script type="text/javascript">
  var myLabel = document.getElementById( 'test' );
  alert( 'myLabel is for: ' + myLabel.getAttribute( 'for' ) );
</script>

There is a workaround for this (see below)

Known Workarounds: Some.

Example Workaround Code:

<script type="text/javascript">
  var myLabel = document.getElementById( 'test' );
  alert( 'myLabel is for: ' + myLabel.attributes['for'].nodeValue );
</script>

Related Issues: None.

bug 268 - hasAttributes not supported in IE

Issue: #268
Affects: IE5, IE5.5, IE6, IE7, IE8 Beta 1, IE8 Beta 2
Fixed In: IE8 RC 1

Example:

<script type="text/javascript">
  var foo = document.getElementById( 'content' );
  alert( foo.hasAttributes() );
</script>

Known Workarounds: Yes.
Example Workaround Code:

<script type="text/javascript">
  var foo = document.getElementById( 'content' );
  alert( (foo.attributes.length > 0) );
</script>

Related Issues: None.

bug 152 - getElementById returns incorrect objects in IE and Opera

Issue: #152
Affects: IE5, IE5.5, IE6, IE7, Opera 8.2, Opera 9.2
Fixed in: Opera 9.50 alpha 1 build 9500
Almost Fixed in: IE8 Beta 1
Fixed in: IE8 Beta 2

MSIE Feedback ID: 333979

Example:

<script type="text/javascript">
  var descField = document.getElementById( 'description' );
  alert( descField.nodeName );
</script>

The above code works perfectly, in all browsers returning the element with the id "description". Well almost. IE will return the element with that id, but it will also return any element with a name set to "description". At first glance this may not seem such an issue, but consider this; Do you have a meta tag on any of your pages? Do any of them have a name attribute with the value description? If so, you will get a reference to the meta tag, not the form element (or whatever you thought you were getting, as indicated in the spec for getElementById).

When you think for a moment, about where the name attribute is set, this becomes rather scary. Any named anchor, can now conflict with your well defined element ids.

Notes:
So you might ask, why is this broken in Opera? Opera is usually pretty good at supporting the specs! Well, it seems that for maximum compatibility with IE, even though it is implemented wrong, they mimicked the broken behavior.

Known Workarounds: No direct methods, using Option #3 below is suggested.

Workaround Option: 1
If you rely heavily on getElementById, and you suspect that you may have name conflicts, or that user specific content added to a page may cause conflicts you can use getElementsByTagName( tagName ) then iterate over the results and compare the value returned by getAttribute( 'id' ).

Example Workaround Code:

var inputs = document.getElementsByTagName( 'textarea' );
var descField = null;
for(var i=0;i<inputs.length;i++){
  if(inputs.item(i).getAttribute( 'id' ) == 'description' ){
    descField = inputs.item(i);
    break;
  }
}

Workaround Option: 2
If you have the ability to globally apply fixes for IE and Opera, the following code will make both of them follow the spec to a 'T', with a very tiny performance hit.

In this example, we redifine the getElementById method, to work as it was intended.
Example Workaround Code:

//use browser sniffing to determine if IE or Opera (ugly, but required)
var isOpera, isIE = false;
if(typeof(window.opera) != 'undefined'){isOpera = true;}
if(!isOpera && navigator.userAgent.indexOf('Internet Explorer')){isIE = true;}

//fix both IE and Opera (adjust when they implement this method properly)
if(isOpera || isIE){
  document.nativeGetElementById = document.getElementById;
  //redefine it!
  document.getElementById = function(id){
    var elem = document.nativeGetElementById(id);
    if(elem){
      //verify it is a valid match!
      if(elem.id == id){
        //valid match!
        return elem;
      } else {
        //not a valid match!
        //the non-standard, document.all array has keys for all name'd, and id'd elements
        //start at one, because we know the first match, is wrong!
        for(var i=1;i<document.all[id].length;i++){
          if(document.all[id][i].id == id){
            return document.all[id][i];
          }
        }
      }
    }
    return null;
  };
}

Oh my! this just gets better and better! (after posting and using this I noted (as did J. Max Wilson) that the second workaround, actually exposes another bug in IE!

Third time's a charm (we hope!)

Workaround Option: 3

Same as workaround 2 above, but rather than test elem.id or elem.getAttribute('id') we'll use the much safer elem.attributes collection. Unfortunately if the element you are looking for, in turn has a child element with a name or id attribute, that is set to "id", it will not test the attribute, but rather the child element. (bug 162 - global namespace pollution)

Example Workaround Code:

//use browser sniffing to determine if IE or Opera (ugly, but required)
var isOpera, isIE = false;
if(typeof(window.opera) != 'undefined'){isOpera = true;}
if(!isOpera && navigator.userAgent.indexOf('Internet Explorer')){isIE = true;}

//fix both IE and Opera (adjust when they implement this method properly)
if(isOpera || isIE){
  document.nativeGetElementById = document.getElementById;
  //redefine it!
  document.getElementById = function(id){
    var elem = document.nativeGetElementById(id);
    if(elem){
      //verify it is a valid match!
      if(elem.attributes['id'] && elem.attributes['id'].value == id){
        //valid match!
        return elem;
      } else {
        //not a valid match!
        //the non-standard, document.all array has keys for all name'd, and id'd elements
        //start at one, because we know the first match, is wrong!
        for(var i=1;i<document.all[id].length;i++){
          if(document.all[id][i].attributes['id'] && document.all[id][i].attributes['id'].value == id){
            return document.all[id][i];
          }
        }
      }
    }
    return null;
  };
}

Related Issues: (bug 154), (bug 411), (bug 162).

bug 411 - getElementsByName doesn't work in IE

Issue: #411
Affects: IE5, IE5.5, IE6, IE7, IE8
Status: Microsoft has confirmed this will NOT be fixed in IE8 RTM

MSIE Feedback ID: 334336

Example:

<script type="text/javascript">
var checkboxOptions = document.getElementsByName( 'preferences' );
alert( 'There are ' + checkboxOptions.length + ' preference options.' );
</script>

Known Workarounds: No direct methods.

Example 1 Workaround Code:
Developers must iterate over all potential tag matches with a call to getElementsByTagName(), then for each NodeList returned, check for a match against the name attribute with getAttribute( 'name' ). Alternatively, if retrieving elements from a form by name, formObj.elements[name]; will return a form element array that will suffice.

Example Workaround Code:

<script type="text/javascript">
//option 1
var inputs = document.getElementsByTagName( 'input' );
var checkboxOptions = [];
for(var i=0;i<inputs.length;i++){
  if(inputs.item(i).getAttribute( 'name' ) == 'preferences' ){
    checkboxOptions.push( inputs.item(i) );
  }
}
var checkboxOptions = document.getElementsByName( 'preferences' );
//option 2
var checkboxOptions = document.forms[formIndex].elements['preferences'];

alert( 'There are ' + checkboxOptions.length + ' preference options.' );
</script>

(Note: If there is only one checkbox, using option 2, the length will be undefined, since browsers treat a single checkbox as an atomic item, but multiple as an array)

Example 2 Workaround Code:
Since IE keeps an associative array in the proprietary document.all object, we can carefully iterate over it to solve this issue. (in theory, code below is untested)

<script type="text/javascript">
//use browser sniffing to determine if IE or Opera (ugly, but required)
var isOpera, isIE = false;
if(typeof(window.opera) != 'undefined'){isOpera = true;}
if(!isOpera && navigator.userAgent.indexOf('Internet Explorer')){isIE = true);

if(isIE){
  var document._getElementsByName = document.getElementsByName;
  document.getElementsByName = function(name){
    var temp = document.all[name];
    var matches = [];
    for(var i=0;i<temp.length;i++){
      if(temp[i].name == name){
        matches.push(temp[i]);
      }
    }
    return matches;
  };
}
</script>

In theory, this should work, but it might need adjusting, if there is only 1 item with the name, and that item, has a length property (e.g. a form, a select list, a radio button or checkbox set.) If you find the perfect solution, please advise.

Related Issues: None.

A day in the life of a Web Application Developer

Once Upon A Time:
Every Web based application has to start somewhere, but I'm going to jump in to a very specific spot.

Every Web based application has forms, likely lots of forms, and each of those forms has buttons, often at least a few.

Buttons are the perfect UI component. Just looking at them it is obvious what to do with them , and design wise they provide the perfect constraints to apply actions to a form.

Buttons usually have words that depict exactly what they are for , they display a pointer cursor when you mouseover them, and they can even be displayed in a disabled state , indicating that a particular action is not available at this time.

As a developer, you have the choice to "roll-your-own" fancy buttons by using images and/or css, but the basic input type="button", does all the work for you.

...

So if they are so perfect, why devote an article to them? ...well, they are great, but there are drawbacks as well.

So its day 2 or 25 or 457 of your web application's life. You've built a pile of forms and pages to interact with your software, and everything is great. In fact, if you take a minute to ponder, those buttons you have, certainly add up... well into the hundreds now, and you add more with every update to the application.

You used the element designed for this task, the <input type="button".../>. Straight "out-of-the-box" they had everything you needed. You could submit forms, execute JavaScript, enable, disable, even change the text on the button, or the value it submitted.

Then one day, things took a bit of a nose dive. Users started to complain that the buttons looked ugly, if they were wordy, distorting as if melting at the sides. Welcome to the world of bugs. This bug, is the famous Windows XP Button bug (bug 101), which under most circumstances, causes buttons with 18 or more characters to start stretching oddly. There are some minor tweaks you can make, to try and fix a bit of the stretching, but they aren't perfect, and they will still eventually fail.

So, depressed and frustrated, you check your specs at the W3C and realize all is not lost, there is a <button>Click Me</button> element that might just save the day!

Shattered Dreams:

After building some super sexy button elements, you figure you have it licked! Not only do these buttons look like buttons, but you can add images, spans of text, line breaks, you name it! Awesome!

Everything is great, until you submit that first form.

Update=<img src="http://www.mydomain.com/img/gear.png" class="icon"/><span class="buttonText">Update Configuration</span>

What on earth is all that garbage HTML when I submit my form? Welcome to (bug 341).

So, using the button element won't solve your problem, and in fact, you can't even use it in your application because one browser "Broke The Web" ^~TM. It's too bad, because beyond the animated GIF bug for buttons (reference), the button element would be the perfect control for great looking Web 2.0 applications.

Like many 12 step programs, you've reached level 1. Admitting defeat. Try as hard as you can to follow the specs and use the proper elements, you have to concede that you may need to do some hacking, or break the rules.

---

You also start getting a lot more emails from users complaining that their auto-completion works fine on other web sites, and applications, but it isn't working on yours? After gathering the info, it turns out that only your IE users are affected.

Strange? Auto-complete is a feature of the browser, and you don't specifically go out of your way to block it anywhere in your application. Turns out, that Auto-complete was implemented in a buggy manner in IE (bug 137) and now your application suffers because of it. At least there is a hackable workaround for this issue.

---

It's the afternoon now, and you're keen to implement a new section in your application. The new section does some neat stuff with AJAX calls to refresh parts of the page with new data, and executes some server-side validation to improve usability. As part of this process, some of the options in some dropdowns need to be disabled.

Everything works fine in Firefox, Safari, and Opera... but before you commit your new code, you test it in IE... What? there's no JavaScript error, but the options do not dynamically get disabled/enabled as needed! You've inadvertently discovered that IE doesn't support disabled options (bug 293) and you struggle to figure out a realistic workaround. Ugh!


The day isn't over yet!... To be continued...

bug 274 - DOM Methods on Select Lists don't work in IE

Issue: #274
Affects: IE6, IE7, IE8, IE9 PP4, IE9 RC 1
Trackers:
MSKB Tracker: 276228

MSIE Feedback ID: 336252
Status: Microsoft has confirmed this will NOT be fixed in IE8 RTM

There is actually several issues with select list elements in Internet Explorer. See the Related Issues section for other issues.

This issue, is the fact that setting the .innerHTML on a select element does not work, and actually appears to render NO options in the list. Some will argue that the .innerHTML property isn't a DOM Method (true), but it has been adopted as a standard method to quickly populate the DOM Fragment inside of an element.

Example:

<script type="text/javascript">
  var myOpts = '';
  for(var i=1;i<32;i++){
    myOpts += '<option value="' + i + '">April ' + i + '</option>';
  }
  var myDaysSelect = document.getElementById('daySelect');
  myDaysSelect.innerHTML = myOpts;
</script>

Select Day:initializing...

(the select should populate with options for the days in April - including the bonus April 31st! - In IE any original options are wiped out and none of the new ones are added)

Known Workarounds: One. Apparently you can add the actual select element content to your string (pre and post) then set the .outerHTML value. NOTE: This will trash any event handlers you have on the original element.

Example Workaround Code:

  Not going to post.  Most advise against this workaround.

Related Issues: (bug 116).

bug 242 - setAttribute doesn't always work in IE

Issue: #242
Affects: IE5, IE5.5, IE6, IE7
MSIE Feedback ID(s): 332453 (events)
332237 (type)
336253 (object, not a string)

336256 (cellpadding, cellspacing)
Partially Fixed in: IE8 Beta 2 (Still does not handle inline events and some developers have reported issues with certain style/class attributes not taking effect right away)


Description: When calling the DOM method .setAttribute( attName, attValue ); in IE, there are several circumstances where it will not work.
Setting the "name" attribute as mentioned (bug 235),(bug 240) does not work, the "colspan" & "rowspan" attributes for th and td tags does not work, the "frameborder" attribute on iframes does not work, nor the "cellpadding" or "cellspacing" attributes on table tags.

Setting any of the inline event attributes does not work either! therefore ALL of the following will not work:

obj.setAttribute( 'onbeforeunload', doSomething );
obj.setAttribute( 'onblur', doSomething );
obj.setAttribute( 'onclick', doSomething );
obj.setAttribute( 'onchange', doSomething );
obj.setAttribute( 'ondblclick', doSomething );
obj.setAttribute( 'onerror', doSomething );
obj.setAttribute( 'onfocus', doSomething );
obj.setAttribute( 'onmousedown', doSomething );
obj.setAttribute( 'onmouseover', doSomething );
obj.setAttribute( 'onmouseout', doSomething );
obj.setAttribute( 'onmouseup', doSomething );
obj.setAttribute( 'onkeydown', doSomething );
obj.setAttribute( 'onkeyup', doSomething );
obj.setAttribute( 'onkeypress', doSomething );
obj.setAttribute( 'onload', doSomething );
obj.setAttribute( 'onsubmit', doSomething );
obj.setAttribute( 'onreset', doSomething );
obj.setAttribute( 'onunload', doSomething );
obj.setAttribute( 'on*', doSomething );

You also can not set the "class" attribute, nor the "for" attribute, or even the "style" attribute.

Example: ...

Known Workarounds: Well there are several, and each depends on which attribute you are trying to set. The following table indicates what you can use to workaround these bugs.

• Attribute: Workaround


• acceptcharset: Use "acceptCharset"


• accesskey: Use "accessKey"


• allowtransparency: Use "allowTransparency"


• bgcolor: Use "bgColor"


• cellpadding: Use "cellPadding"


• cellspacing: Use "cellSpacing"


• checked: See note (bug 299)


• class: Use "className"


• colspan: Use "colSpan"


• defaultchecked: Use "defaultChecked"


• defaultselected: Use "defaultSelected"


• defaultvalue: Use "defaultValue"


• for: Use "htmlFor" (also note potential side issue: bug 116)


• name: None - see (bug 235),(bug 240)


• type: See note (bug 237) "type" is readonly in IE


• frameborder: Use "frameBorder"


• hspace: Use "hSpace"


• longdesc: Use "longDesc"


• maxlength: Use "maxLength"


• marginwidth: Use "marginWidth"


• marginheight: Use "marginHeight"


• noresize: Use "noResize"


• noshade: Use "noShade"


• on*: Inline events can not be set in IE, attach event handlers instead


• readonly: Use "readOnly"


• rowspan: Use "rowSpan"


• selected: When setting multiple selected items in a "select multiple" this will fail. {bug ref#TBD}


• style: None - see (bug 245), (bug 329)


• tabindex: Use "tabIndex"


• valign: Use "vAlign"


• vspace: Use "vSpace"

Example Workaround Code:

//set variable IE=true when User Agent known to be IE.
if(!IE){
  obj.setAttribute( 'class', 'special' );
} else {
  obj.setAttribute( 'className', 'special' );  
}

bug 153 - Self closing script tag issues in IE

Issue: #153
Affects: IE5, IE5.5, IE6, IE7
Description: Adding a self closing script tag in IE, causes rendering/execution issues.

The script tag has 2 basic structures:

<script type="text/javascript">
 //inline script content...
 var now = new Date();
</script>

or:

<script type="text/javascript" src="external.js">
 //inline logic to execute if loading external script fails
 alert('Could not locate external.js');
</script>

Now as a Web developer, the error condition shouldn't really happen, and in most cases is something we'd rather just quietly ignore if it fails. Therefore to minimize the amount of markup sent to the client, this would be the optimal code when referencing an external file:

<script type="text/javascript" src="external.js"/>

However in IE, this will cause rendering issues ranging from a partial script execution to a completely blank page.

What happens is IE doesn't "see" (ignores) the close for this tag, and continues to scan for a closing script tag e.g. "</script>". If it finds one (anywhere in the head tag of the document, then all content in between, will not be executed (i.e. this is treated as the "loading error" logic, resulting in the "partial script execution". The more severe outcome, is if NO closing script tag is found in the head tag, in which case IE considers everything it does find, to be part of the "loading error" logic, and thus renders NOTHING at all!

Some would argue, that since the spec (W3C HTML4.01 - Script Tag) states that the closing tag is required, that IE is not breaking any rules, but most would tend to highly disagree.

Example:

<script type="text/javascript" src="file1.js"/>
<script type="text/javascript" src="file2.js"/>
<script type="text/javascript">
 var now = new Date();
</script>

In IE, file2.js will not be loaded, and 'now' will not be set.

Known Workarounds: To avoid this bug, change all references to scripts to have a seperate closing tag, even if there is no content in the tag.

Example Workaround Code:

<script type="text/javascript" src="file1.js"></script>
<script type="text/javascript" src="file2.js"></script>
<script type="text/javascript">
 var now = new Date();
</script>

Related Issues: One.
If you find you are getting blank pages, and this issue doesn't fit your scenario, check if this is the issue you are having:
ASP.NET White screen bug (HTTP 413 Request Entity Too Large)

DOM Method Support - What dreams are made of...

In the ideal world, each and every browser would support these properly, and development would be a breeze... but alas, that is not the case.

For each method listed below, I'll link to the various bugs in terms of their implementation.

getElementById( id )

What seems like the most simplistic method available, yet also one of the most powerful, is unfortunately broken. (bug 152) describes how Internet Explorer, will return an element, if it matches by the id attribute as designed, but will also return a match based on the name attribute. It will also disregard your case-sensitive searches and return elements with IDs with non-matching case (bug 154).

createElement( type )

Another super simple, but super useful method, is again plagued with issues. The correct syntax is:

var myDiv = document.createElement( 'div' );
//or
var myHeader = document.createElement( 'h2' );
//or
var myTextBox = document.createElement( 'input' );

Well, lets say you are building up some form elements on-the-fly (very common in today's Web 2.0 world). Say you want to add a hidden field named "showOption" that you will pre-populate with the value "messages", just before the form is submitted to take the user directly to a certain screen.

The code would look something like this:
development would be a breeze... but alas, that is not the case.

var hiddenOption = document.createElement( 'input' );
hiddenOption.setAttribute('name', 'showOption');
hiddenOption.setAttribute('value', 'messages');
hiddenOption.setAttribute('type', 'hidden');
var myForm = document.forms[0];
document.appendChild(hiddenOption, myForm);
myForm.submit();

So as long as you have a form, this should work! Well, not in Internet Explorer!

As it turns out, in (bug 235) Internet Explorer, you can't set the name attribute on an Element... any Element! To overcome this, there is a hack, which explains why the createElement method is broken (bug 124) in IE. To make the above code snippet work in IE, you need to do this:

var hiddenOption = document.createElement( '<input name="showOption">' );
hiddenOption.setAttribute('type', 'hidden');
hiddenOption.setAttribute('value', 'messages');
var myForm = document.forms[0];
document.appendChild(hiddenOption, myForm);
myForm.submit();

Did you spot the changes?

Change#1.) The Element we create is a string that is the HTML tag, with the name attribute. This is not only quite ugly (mixing tags in strings), but also completely against the spec! document.createElement Spec Reference.

Change#2.) We moved the "type" attribute up to be the first attribute set. The reason for this, is that in IE you can't change the type attribute (bug 237) after the node is added to the DOM, and the default type is always "text". In this code snippet, it didn't matter, but if we had added this to the DOM, before setting the type, we would have been stuck.

Modern Browsers

Modern Browsers: I expect this to be a moving target, but as of mid-2007 I would only qualify the following as "Modern Browsers". You should expect to see little support, and very few features for browsers not listed here. If your Web Browser is not listed here, it IS time to upgrade.

• Mozilla
  
  
  
  • Mozilla
  
  
  • Firefox 1.5* | 2.0 | 3.0 | 3.5
  
  
  • Camino 1.5
  
  
  • Epiphany 2.2
  
  
  
  


• Opera 8.0 | 9.0 | 9.5


• Safari 3.0 | 3.1 | (4.0*)(Mac or Windows)


• Konqueror 3.5 | 4.0


• Google Chrome 1.0 | 2.0 (based on WebKit)


• Netscape 7.0 | 8.0 | 9.0


• AT&T's Pogo (based on Firefox) [in Limited Beta]


• Internet Explorer 7.0 | 8.0 | 9.0***

***IE9 announced at PDC and on the IE Blog

*Safari 4.0 is now out in Beta for Mac and Windows

*Firefox 1.5 is a modern web browser for sure, but with the fast pace of Firefox development, full support for this version has already moved on. If you are using Firefox 1.5 we strongly suggest you upgrade to Firefox 2.x or, if 3.x when it is available.

Web Design - Side Notes

Side Note: #1
If you use document.write(), be sure to use document.close(), especially if you are writing to a popup window... or the throbber will throb as if the page is still loading.

Side Note: #2

Side Note: #3
Does your web application need to ensure that a user only clicks a link once?

Well, there is no easy way to do this, but here's a few tips:
1a.) Use JavaScript to do the link (via location.href), and set some sort of flag and stop the user on the 2nd - nth time.

1b.) If you are using a link, use the onclick attribute instead of the href attribute. If the user presses Escape, or another link before the first link gets to the server and back, then the first request will get canceled. Using any of the "event" attributes will trigger a request that can't be canceled by the end user.

2.) Keeping 1b in mind, use an <input type="button"/> element. With a button, you can also disable the button after the first click, so the user knows it can't be clicked again.

bug 186 - Can't prototype on HTMLElements in IE

Issue: #186
Affects: IE5, IE5.5, IE6, IE7, IE8 Beta 1

MSIE Feedback ID: 333956

Description: The ability to prototype on any HTMLElement (doesn't matter which kind, e.g. HTMLFormInputElement, HTMLFormButton, etc. (see all element types)) is not possible in Internet Explorer. This frustrates many developers because being able to do so would allow them to workaround almost any other bug in IE.

Example: calling HTMLFormElement.prototype.preSubmit = function(){...} will not work, although it works in all other Modern Browsers.

Known Workarounds: None.

Related Issues: Any issue with missing or broken implementations for other elements in Internet Explorer.

bug 137 - IE AutoComplete hardly ever stores data

Issue: #137
Affects: IE5, IE5.5, IE6, IE7, IE8 Beta 1, IE8 Beta 2, IE8 PR1, IE8 RC1
Description: When a form is submitted, by any method other that an input button of type="submit", the data in the form is NOT stored for future use in AutoComplete.

Example: calling document.forms['foo'].submit(); from JavaScript will not save the form contents for future use.

Known Workarounds: According to this KB article KB:329156, explicitly calling this function, before calling .submit(); will store the data in the AutoComplete history.

Example Workaround Code:

function fixSubmit(formObj){
  window.external.AutoCompleteSaveForm(formObj);
  formObj.submit();
}

Related Issues: The workaround for this bug, could be directly incorporated into the .submit() method for all forms on a page, by prototyping a .submit() wrapper on the HTMLFormElement object, however due to bug 186, this is not possible.

Microsoft Internet Explorer

Microsoft Internet Explorer (IE):

Developing for the IE browser is quite challenging, due to all the bugs. For example, if your form doesn't get submitted, by clicking on an input element of type="submit", IE won't save the users info for future use with the AutoComplete feature (bug 137). This would be easily solved, if you could use JavaScript to prototype on the HTMLFormElement, but that too (bug 186) is not possible. Other bugs like (bug 153) cause frustration because the code appears to be completely fine, but renders errors/blank pages in IE. Best of all, when developers start using the Browser-Independent DOM Methods, they still lose out! IE doesn't support the .setAttribute() method properly (bug 242) and the .getElementById() method returns incorrect data! (bug 152).

Some bugs are just so strange, like the Magic Mystery HTTP Requests (bug 223), and then there are the bugs discovered when a workaround is discovered for another bug (but we'll let you see if you can find those ones!)

FAQ - Frequently Asked Questions

Q: Is this a Blog or a Bug Tracking site?

A: Both! If this grows immensly, I'll likely build it into its own site, but for now, its a Bug Blog.

Q: If I found a bug and I want to add it to your list, can I? and if so how?

A: Sure thing! I've turned comments off on a bunch of the posts, but if you have found a bug you want to share, jump to the Bug Submission page, and add the details in a comment.

Q: What if I have a question about this site, that isn't about a bug, how can I contact you?

A: I've made another post for Site Feedback, feel free to leave a comment there.

Q: Are the bug numbers in any sort of sequence?

A: They are just random numbers. In time, the "gaps" between the bug numbers will fill up.

Q: All the bugs seem to be for Internet Explorer, what gives?

A: The conspiracy theorists would likely claim a bias, however the bugs are merely listed based of the frustration level they cause developers. If you have a really annoying bug in Camino, Firefox, Konqueror, Maxthon, Opera, Safari or other, by all means submit it! I'd be glad to include it.

Q: Why don't you allow comment on the individual bug entries?

Unlike a typical blog, I intend to update each section as more content becomes available, so this may end up more like a wiki than your typical blog. I wanted a tool to quickly build up a site with content, for tracking bugs in browsers... and blogging software fit the bill. I just wanted something that would allow me to post an "article" on an issue, and thus be trackable by others.

It may roll out in to a full fledged site at some point, with a proper DB, PHP Framework etc. however I didn't want to do that until there was (A) a reasonable level of content, and (B) I had a sense of whether MS was planning to re-open their bug tracking system.

For item (B) as previously mentioned I'll certainly link into it once it becomes available, but I didn't want to invest too much time and effort, if MS was "just about" to roll out their own.

Anyway, the comment thing... I didn't want a huge trail of mis-information in the comments, that you typically see on other blogs. The final workaround is usually partly in the article, then that little snippet from comment 34, and the hack from comment 71 or 83. For the poor web developer just trying to make sense of it all, a consolidated view is needed. (not to mention the quantity of spam/troll comments)

Thus I have the Site Feedback, and Submit a Bug links, that anyone can post comments to. I take that info (there's been several additions already) and update/revise the articles accordingly.

Site Feedback

Did you find a bug with this site? or want to provide some sort of feedback?

Drop me a line below, I'll be sure to check out what you have to say. If you want to submit a bug report on a browser, or framework / programming language, use the Submit a Bug form instead.

Cheers,
xyz

Submit a Bug!

So, you found a bug you'd like to share? Great! Add a comment below with the details, and I'll be sure to include it and all applicable links.

If you have a comment about this Blog though, please add it on the Site Feedback page, or for any other questions, try checking out the FAQ page.

Thanks.

Oh, one last thing! If we verify that the bug is truly an issue (e.g. not just a misconfiguration), then we'll also submit a bug to the applicable Browser maker, and update this blog with the tracker ID and a direct link. ;-)

Welcome to Web Bug Track

This blog is for tracking Web Bugs. Mostly Browser bugs, however the occasional framework/language bug might sneak in. Where possible, I'm going to try and link into other public bug tracking systems, so you can track their progress directly from the Browser Developers.

Unlike a typical blog, I intend to update each section as more content becomes available, so this may end up more like a wiki than your typical blog.

So, if you want to get started, just follow the links below, or pick a Category in the Tags section.

Browsers:
Mozilla (Firefox), Microsoft Internet Explorer (IE6, IE7), Apple Safari, Konqueror, Opera.

Languages:
HTML, XHTML, JavaScript, DOM, CSS, PHP, JSP, XML, XSL, RSS, XUL, SVG, ASP, CF