bug 119 - no title for options or select in IE6

Issue: #119
Affects: IE6
Fixed In: IE7

Note: Updated synopsis to include the select element, not just the options.

Have you ever wanted to provide more descriptive text in the form of a tooltip in your Web applications? Of course you have. It may have slipped your notice though, that this doesn't work on select list options (or even the select list itself) in IE6 (fixed in IE7).

Example:

<select size="3">
  <option value="1" title="Web Bug Track">WBT</option>
  <option value="2" title="Bugzilla Bug Tracking">Bugzilla</option>
  <option value="3" title="Tracker Bug Track">Tracker</option>
</select>

WBT
Bugzilla
Tracker

Known Workarounds: None.

Related Issues: (bug 291) (bug 280).

Bug/Site Feedback |
Submit a bug

feature 266 - window.prompt() in Safari is multiline capable!

Issue: #266
Affects: Safari 3.1/Win, 4.0 Beta/Win (readers report that this feature isn't available on the Mac)

The window.prompt() function when it first became available would allow a user to add 1 (one) line of text as an input value using a modal dialog supplied by the browser.

It turns out though, that Safari now allows users to enter more than one line of text (Enter is treated as a request for a carriage return, not to accept the value and submit the dialog).

I don't consider this a bug, but rather an enhancement to the existing dialog. (In Safari's case, it could do with a scrollbar, since it does allow more than the 3 lines it visually displays)

However this is something that developers will want to be aware of... that line breaks should be expected in the return value from the prompt call.


Try it!:



Related Issues: (bug 109), (bug 139).

Bug/Site Feedback |
Submit a bug

bug 417 - isNaN() might return false when you expected true

Issue: #417
Affects: All Browsers

The JavaScript isNaN(testValue) function will return true if the testValue is Not A Number. Likewise a false return value would signify that the testValue was actually a number.

isNaN('foo');//true
isNaN(37);//false
isNaN('123456789w');//true
isNaN('12345e6789');//false

Huh?! What?! but there is a letter in there!

Since Scientific notation allows the letter 'e' to be used to indicate very, very small and very, very big numbers ("e" represents "times ten raised to the power"), one can only guess that the parsing allows all digits, zero or one decimal, AND zero or one 'e' character...

Tuck that one in your JavaScript toolbelt for a rainy day. ;-)

Known Workarounds: One. If this truly worries you when reading in a value, you can run an additional test against the string...

Example Workaround Code:

  var testStr = '12345e6789';
  var isNumber = !isNaN(testStr);
  if(isNumber){
    if(testStr.indexOf('e') != -1){
      isNumber = false;
    }
  }
  alert('The test value is a number?: ' + isNumber);

Keep in mind, that '123e14' is a valid number, just likely not what your application is expecting in terms of the size of the number. ;-)

Related Issues: None.

Bug/Site Feedback |
Submit a bug

bug 255 - animated GIF image rendering issues in IE

Issue: #255
Affects: IE6, IE7, IE8

In general IE has no issues rendering Animated GIF images... however with all this Web 2.0 stuff going on where animated "spinners" are used to indicate "activity" in AJAX applications a bug has started to become exposed.



It is common to have a pre-loaded animated GIF image rendered as part of a page, that has its style (or a wrapping element) set to display:none;

Then whenever it is needed, simply setting the display to 'inline','block' or even '' will then display the animated image.

The problem is, that sometimes IE refuses to animate the image. It just sits there in a still frame as if there were no animation sequence.

It appears to be some sort of threading/race condition and is most obvious if right after setting the display back to a "visible" state the location.href is changed, or the form is submitted.

Its one of those odd bugs that doesn't always happen, but appears "glitchy" when it does.

Example:

<img src="img/busy.gif" width="16" height="16" border="0" style="display:none;"/>
<script type="text/javascript">
  var busy = document.getElementById('busyicon');
  busy.style.display = 'inline';//or try '', or 'block'
  document.forms[0].submit();
</script>

Known Workarounds: Some kind of sorta? There are various speculations on this (and I'm opening comments on this to bring in more), but anything that attempts to reload the src of the animation afterwards, or in another thread appears to help.

Example Workaround Code:

<script type="text/javascript">
  //spawn another thread to show activity
  setTimeout('showSpinner',150);//spawns another thread to kick off after the submit
  document.forms[0].submit();

  function showSpinner(){
    var busy = document.getElementById('busyicon');
    busy.style.display = 'inline';//or try '', or 'block'
  }
</script>

Related Issues: None.

Bug/Site Feedback |
Submit a bug

bug 289 - popup window name can't have spaces in IE

Issue: #289
Affects: IE6, IE7, IE8

Note: Readers are indicating that you can't use dashes in IE either! e.g. 'this-name-fails'

When you open a popup window in your web applications using the JavaScript window.open() function if you must specify the name of the window, it mustn't contain spaces in IE, or the function will fail to open the window.

Example:

<script type="text/javascript">
  var url = 'http://www.google.com/q?Hello=World';
  var featureList = 'width=500,height=400';
  var childWin = window.open(url, 'name of child win', featureList);
</script>

Known Workarounds: One. Quite simple. Be sure that all your popup window names do not contain spaces.

Note: Readers are indicating that you can't use dashes in IE either! e.g. 'this-name-fails'

Example Workaround Code:

<script type="text/javascript">
  var url = 'http://www.google.com/q?Hello=World';
  var featureList = 'width=500,height=400';
  var childWin = window.open(url, 'name_of_child_win', featureList);
</script>

Related Issues: None.

Bug/Site Feedback |
Submit a bug

Bug or Feature? - Round Three

Round Three - If more than one ID, which one matches?

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

We're back again with another round of "Bug or Feature?" (see round one) 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 todays "Bug or Feature"?

Synopsis:
The HTML id attribute is designed to uniquely identify a particular element.

However, what if you accidentally end up with 2 or more elements with the same ID?
Obviously this is a bug, but how different browsers handle it, is what makes it interesting.

All browsers tend to return the first matching element in the DOM order with the same id when using .getElementById(id). However if you have an HTML Label element, with a for attribute that points to the id attribute of a field, things aren't quite so clear.

Firefox, Safari & Opera all link to the first form element with the matching id.
Internet Explorer links to the last form element with the matching id.

Question is, is IE's different behavior a bug? or a feature?

Example HTML snippet:

<label for="obj1_prop1">Size:</label>
<input id="obj1_prop1" type="text" size="5">
<label for="obj1_prop1">Quantity:</label>
<input id="obj1_prop1" type="text" size="5">

Question:
Does linking to the last element vs. the first element expose a feature? or is it a bug?

Test it for yourself, click on the labels Size and Quantity:
Size:

Quantity:


Is this a Bug? Or a Feature?

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