bug 263 - beware of DoubleClick in IE

Issue: #263
Affects: IE6, IE7, IE8, IE9 PP1, IE9 PP2, IE9 PP3
Fixed In: IE9 Platform Preview 4 both the extra mousedown and click events now fire!

Satus Update: IE9 Platform Preview 2 shows some improvement and actually does fire the 2nd mousedown event - however it still does not fire the 2nd click event.

Attempting to track events in the process of a doubleclick event in IE will be entertaining to say the least.

The normal sequence of events fired leading up to a doubleclick go as follows.

• mousedown


• mouseup


• click


• mousedown


• mouseup


• click


• doubleclick

but in IE, if you doubleclick on a link, and image or any element, the events fired are:

• mousedown


• mouseup


• click


• mousedown


• mouseup


• click


• doubleclick

Thats right, no second mousedown?, and no second click!
As a developer, if you are tracking mousedown, mouseup, and click events... you need to be aware of this because if your users doubleclick by accident any actions that are designed to "stop" onmouseup might try and reference something that wasn't started... and if the onclick was being used to quit listening for example... that event may never fire.

Example:


Double Click Me To Test!

Event Log

Known Workarounds: None.

Related Issues: None.

Bug/Site Feedback |
Submit a bug

Internet Explorer 8 (IE8) - Facts and Fiction

Microsoft is well underway with development of their new Web Browser Internet Explorer 8. As development moves ahead into the Alpha/Beta 1, Beta 2 RC1 testing stages this post will attempt to condense the knowns and the unknowns to give you a better idea of what to expect in IE8.

Release Schedule:

• Beta 1: Released March 5th, 2008 (IE Blog post, Download Link, IE8 Feedback (Bug Tracker for IE8 (invite only))
  


• Beta 2: "Later this year" - Chris Wilson [MSFT], Helen [MSFT]


• Beta 2: "August 28th, 2008" - Mary Jo Foley [ZDNet], Helen [MSFT]


• Beta 3: ???


• PR1: Partner Release 1 - A semi-private release was made available on Dec. 10th, 2008



• RC1: RC1 Released Jan. 29th, 2009 (Dean on IE Blog)


• RC2?,RC3?: Q1 2009 (Dean on IE Blog)


• Final RTM: "November 2008" - Mary Jo Foley [ZDNet], Helen [MSFT]

Operating System Support:

• Microsoft Windows
  
  
  
  • Windows XP
  
  
  • Windows Vista
    The User Agent string was confirmed, it will be:
    
    
    
    • Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0)

Fixed / Implemented:

• Passes ACID2 CSS Stress Test ⁽¹⁾


• CSS display: table implemented ⁽¹⁾


• HTML <abbr/> implemented ^(?)


• Object Fallback ^(?)


• Data URIs ^(?)


• CSS position: fixed ⁽¹⁾


• CSS generated content ^(?)


• WBT (bug 101) - Fixed in IE8 Beta 1


• WBT (bug 152) - Fixed Properly in IE8 Beta 2


• WBT (bug 163) - Fixed in IE8 Beta 2


• WBT (bug 190) - Fixed in IE8 Beta 2


• WBT (bug 229) - Fixed in IE8 Beta 1


• WBT (bug 341) - Fixed in IE8 Beta 1


• WBT (bug 403) - Fixed in IE8 Beta 2




• The following are untested, but according to IE8 DOM whitepapers (here) are apparently fixed! ;-)
  
  
  
  • getAttribute()!, setAttribute()!, getElementById()!, <button> element submits the correct value attribute!,
  
  
  
  

Remains Unfixed (e.g. Intentionally not fixed):

• {nothing confirmed}


• WBT (bug 126) - MSFT Status: Will not fix in IE8


• WBT (bug 193) - Tested, Still Broken in IE8 Beta 1


• WBT (bug 256) - Tested, Still Broken in IE8 Beta 1, IE8 Beta 2


• WBT (bug 263) - Tested, Still Broken in IE8 Beta 1, IE8 Beta 2


• WBT (bug 280) - Tested, Still Broken in IE8 Beta 1, IE8 Beta 2


• WBT (bug 291) - Tested, Still Broken in IE8 Beta 1


• WBT (bug 293) - Tested, Still Broken in IE8 Beta 1

Possibly Fixed?:

• JavaScript and DOM Fixes? Feb 4th post by Web Standards group indicates Microsoft may address many open issues.

Caveats:
?.) Unknown
1.) In "IE8 Standards Mode"

IE8 Standards Mode:
The current trigger for IE8 Standards Mode is under heavy debate over on the IE Blog, A List Apart, WaSP, John Resig (jQuery), Dean Edwards, Robert O'Callahan (Mozilla), and Maciej Stachowiak (Safari). The proposal below *may* be revoked in favor of a more clever approach.

<meta http-equiv="X-UA-Compatible" content="IE=8"/>

or it can be sent as an HTTP header:

X-UA-Compatible: IE=8

or if you want to live on the bleeding edge, and always render in the strictest mode possible, use this meta tag:

<meta http-equiv="X-UA-Compatible" content="IE=edge"/>

Information Sources:
MSDN: Channel 9 Video with IE Team on ACID2 Test Milestone
A List Apart: Beyond Doctype
IE Blog: ACID2 | IE8 Standards Mode | User Agent String

WinVistaClub: IE8 Beta release date

Bug/Site Feedback |
Submit a bug

Bug or Feature? - Round One

Round One - Live .innerHTML in IE

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

We're adding a new post type here, called "Bug or Feature?". It highlights 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.

Ok, so what is the "Bug or Feature" for today? - Glad you asked.

Synopsis:
In IE, if you ask for the .innerHTML of an element, you will get a 'DOM' fragment representing the inner HTML content (and every other browser will do the same). However there is a catch.

If I have the following HTML, I would expect it to return the same content:

Example HTML snippet:

<div>
<input type="text" name="yourname" value="first last" size="25"/>
</div>

Expected [div].innerHTML returned:

<INPUT size=25 value="first last" name=yourname>

Not quite what was entered, but in IE you'll get your tags in UPPERCASE, attributes with no spaces returned with no quotes, no "type" attribute if its a text field and no self closing tag "/" (slash).

Question:

If the user typed "Joe Bloggs" into the field after the page loaded, and you asked for the .innerHTML, (unlike other browsers) IE returns:

<INPUT size=25 value="Joe Bloggs" name=yourname>

Try it yourself.

Is this a Bug? Or a Feature?

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

bug 251 - type more if you are not on port 80

Issue: #251
Affects: IE6, IE7
Status: [By Design]

The default port for most Web Servers is port 80. However as a developer, you might have multiple Web Servers running, or special Web Interfaces to your Database or Application Server running on other ports.

Where is this going? Well as a developer, you are likely typing in your site/application hostname in the location bar several times a day while developing/testing.

http://localhost is fairly easy to type, as is http://barney (if thats what your host is named). However the good folks making Browsers made "http://" the default, so you can save yourself 8 (eight) keystrokes if you leave it out. localhost or barney should work just fine.

Now lets say you are trying to get to your Application Server Web Console:

JBoss: http://barney:8080/jmx-console
WebSphere: http://barney:9091/admin
IIS: http://barney:8172/
Ruby On Rails: http://barney:3000

or a web server on a portable USB stick or iPod
http://localhost:81/

If you type in the full URI for these consoles/alternative Web Servers, you will get what you expect.

Even if you drop the "http://" part, you will get what you expect (console/web server), since the browser defaults to http://. However if you are using IE 6 or IE 7, you will get an error!

The webpage cannot be displayed

Its a minor issue, but if you are typing URLs every day, little things like this will drive you nuts.

Status Update:
Well it turns out this isn't a bug. Eric Lawrence from the IE Development Team (and Author of Fiddler Web Debugging Proxy) points out that somevalue:someothervalue is a valid URI, and thus IE is doing the correct thing, looking for an application to handle the URI.

Known Workarounds:
Since this really isn't a bug, there is no workaround however if you pre-pend your hostname with // you will get the page you expect.

So:
//barney:8172/ will actually work.

Bug/Site Feedback |
Submit a bug

Official Browser Bug Tracking

As readers may recall from the Welcome Page this site was created to fill a gap between existing and non-existing bug tracking databases for Web Browsers.

As a service to Web Developers everywhere that just want to know how to workaround some of the most annoying browser bugs and/or find out when they will be fixed, this site was put together.

As mentioned from the onset, the idea was to tie into existing bug tracking systems wherever possible, and provide updates when the status of any bug changes.

In addition, we think it is important to provide info on the official bug tracking systems, as this site is by no means a complete solution. The following list indicates the bug tracking system available for each Web Browser:

Official Public Bug Tracking Sites:

• Mozilla/Firefox: Mozilla Bugzilla


• Google Chrome: Chromium Isues


• Internet Explorer: IE Feedback, IE8 Feedback (reopened for IE8 Beta cycle)


• Safari: WebKit Bugzilla


• Konqueror: KDE Bug Tracking System


• Opera: Opera Bug Tracking


• Maxthon: Maxthon Forum (note: for bugs in the browser layout / rendering, see IE bug tracking)

Unfortunately Microsoft seems to not be interested in receiving any bug reports for IE (6 or 7). This doesn't sit well as a company policy as Browsers move ahead as the default development platform of Enterprise Applications however we hope that as IE8 appears over the horizon, that they realize the mistake in this approach and provide public tracking of issues.

Bug/Site Feedback |
Submit a bug

bug 524 - IE's Object doesn't support this property or method

Issue: #524
Affects: IE6, IE7, IE8 Beta 1, IE8 Beta 2, IE8 PR 1, IE8 RC1

In the world of software programming errors and warnings will always occur. When an error does occur though, providing the programmer with information as to what went wrong is as important as catching the error in the first place.

If the title of this post was familiar?

Object doesn't support this property or method then you've likely encountered this one more than once in Internet Explorer.

It is about as helpful as someone saying "hey you shouldn't do that" when you accidentally drop your ice cream cone in the sand at the beach. I can tell that something went wrong, how about some help rather than pointing out the fact that something failed.

A simple Object foo does not have a property or method named bar defined

This would give the developer a much better chance of finding the issue at hand, since the bug line number has been notoriously incorrect in IE for years (I'll leave that for another bug filing).

With this info I know exactly which property or method is missing on exactly which object.

Oddly enough, other browsers seem to have no problem providing this kind of info in their JavaScript console debug messages, stack traces or Firebug (if you are using Firefox)


Example:

Known Workarounds: None.

Related Issues: None.

Bug/Site Feedback |
Submit a bug

Browser Preferences - Poll Results

It isn't much of a surprise, but lets review the findings.

Several weeks ago, we opened up a poll asking you what your favorite Web Browsers were. As a site delivering content mainly to Web Developers, it came as no surprise that Mozilla Firefox was by far the most favored Browser.

Favorite Browser Poll Results:




What is interesting to see, is the breakdown of other Browsers. Keep in mind, these are "preferred" Browsers, not necessarily reflecting spec compliance, features or bugs, but rather what you prefer as a browser.

Thus a new poll has opened, asking you what features in a browser are most important to you? Do you care about add-ons? Do you care about Specs? Do you care about speed? etc.

Feel free to choose your favorite features in a Browser (any browser) as we dig deeper into what makes a good browser, and thus what features we would like added, or bugs we'd like fixed in other browsers.

Happy New Year!

Bug/Site Feedback |
Submit a bug