Web Bug Track - A place to track Web bugs... in JavaScript, DOM, CSS, XHTML, HTML in all Web Browsers... Firefox, Internet Explorer, Safari, Chrome, Opera, Konqueror and more.
As more and more applications go online in this Web 2.0 world, interactions with forms are critical to an applications success. Safari leads the way with built-in textarea resizing but it has a major issue with form field focus.
Since data entry in forms is a crucial part of online forms, ensuring that your forms are both keyboard and mouse navigable is important. Unfortunately in Safari the keyboard navigation breaks if you use the mouse on radio or checkbox elements. This becomes a major issue because although radio and checkbox elements are keyboard accessible, in general users prefer to use the mouse to make their selection(s).
The issue is this. If you use the mouse to select a radio or checkbox field one expects that that field has the focus and thus a 'Tab' will take you to the next available field (or whatever is defined in the tabindex order). When the user presses 'Tab' in Safari, the focus resets to the first form field on the page!
If you use the mouse for other types of fields, or use only the keyboard the issue doesn't occur.
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: In Safari, usability of textarea elements has been greatly improved by allowing the user to decide how wide and how tall it should be, by making a grippy that the user can drag to stretch. Its a great feature, that many other browsers are looking into (Ask ASA, it's on his top 10 for Mozilla Firefox).
What is interesting, is that as a developer, if you ask for the .innerHTML of an element that wraps a textarea in JavaScript, it will report back exactly what you supplied... *except* if the user changed the dimensions of the textarea, the style attribute is now filled with margins, paddings, width and height values that you didn't specify.
If I have the following HTML, I would expect it to return the same content:
Example HTML snippet:
<div> <textarea name="a_textarea" cols="40" rows="4"> Hello World </textarea> </div>
Expected [div].innerHTML returned:
<textarea name="a_textarea" cols="40" rows="4"> Hello World </textarea>
Question:
If the user stretches the textarea in Safari (or later in other browsers), and you asked for the .innerHTML and got something different than the HTML fragment above...
Try it yourself.
(ignore the br tag in the alert (blogger auto-inserts this)
Related to (bug 411), another bug with getElementsByName( name ); has been noted.
If you dynamically change the name attribute of an element (e.g. an input box) it will affect the form submission, but in IE it won't actually change the name attribute. See these bugs: (bug 199), (bug 235), (bug 237), (bug 240) & (bug 242)
What this also means, is that in IE, if you try to retrieve the elements you have renamed, you will not be able to retrieve them.
Example:
<script type="text/javascript"> var myElem = document.forms[0].elements['oldname']; myElem.name = 'newname';//can't use .setAttribute() due to another IE bug
//how many elements with the name 'newname' do we now have? alert(document.getElementsByName('newname').length + ' elements found!'); </script>
In IE6, attempting to use a valid class name that starts with an underscore will fail.
Example:
<style type="text/css"> ._myCSSClass { /* This is a valid Class Name, but it will fail in IE6 */ border: 1px solid #ff0000; margin: 1px; padding: 3px; } </style>
Known Workarounds: None. The only option is to name all classes with an initial [a-zA-Z] character.
Example Workaround Code:
<style type="text/css"> .myCSSClass { /* This is a valid Class Name, AND will work in IE6 */ border: 1px solid #00ff00; margin: 1px; padding: 3px; } </style>
Issue: #333 Affects: IE8 Beta 1 - IE8 RTM? StatusFixed in IE8 PR1 (see notes) MSIE Feedback ID: 331735
According to blogs around the 'Net and the IE Feedback site Microsoft has dropped all support for CSS opacity in IE8.
This includes the CSS3 property:
opacity: 0.25; AND filter:alpha(opacity=25);
Apparently this is "By Design". As a developer I seriously hope they reconsider this. The filter hack wasn't the best, but no method to set opacity is certainly not "innovation".
Known Workarounds: Fixed (Notes): One. As part of IE8's push towards better supporting Web standards they needed to alter the syntax of the proprietary filter() syntax. To make opacity work in IE8 (and all browsers), you'll need to do this.
In our last poll, we asked if you felt that IE8 would fix their DOM Support? The poll was live long before the IE8 Beta 1 came out and thus nothing was known about the new version since Microsoft isn't very forthcoming with sharing a road map with developers.
Regardless, the mood of the development community was reflected in the results that came in before the beta release, and was only slightly different after developers got some first hand experiences.
Results: Yes Completely - 4% Not A Thing - 16% Minor Fixes Only - 15% Mostly Fixed - 3% Fix Some, Break Some - 30% I Don't Care Anymore - 5% Don't Make Me Laugh - 27%
To be honest, most were taken back by Microsoft's commitment towards standards, and actually taking the (correct) brave step to render in Standards Mode by default.
Many of the long standing bugs DOM Bugs were fixed, although there were many that didn't see any attention at all. New features were added, but the overall UI was hardly improved upon at all (from legacy chrome/usability bugs, to the un-movable toolbar issues).
If history of IE7 development is to repeat itself, expect a few more betas for IE8, then an RC (Release Candidate), and a final RTM (Release To Market) date sometime late in Q4, 2008 or Q1, 2009 if they continue to fix ignored issues.
As noted here day 1, we promised to link into the public bug tracking systems for each browser, when and where they became available (and we certainly have done so - if you find a bug listed here that doesn't reference the IE Feedback bug number, please let us know!). When IE8 Beta 1 was released, Microsoft re-opened their "IE Feedback" site at Microsoft Connect, so that developers could view and track bugs with input from Microsoft. It isn't a full public bug tracking site, but it has been dearly missed since it was dismantled after the IE7 release, in fact one of the reasons that this Blog started! ;-)
We wish the IE Team the best of luck on shipping IE8 with great DOM Support to an eager developer base, lets just hope we can close a bunch more issues before it is shipped out the door!
What!? you say? "They added this in IE7!" - Well yes, no, not quite!
Microsoft did add a non-ActiveX version of XMLHttpRequest ("XHR") so that if a user had turned off ActiveX for security reasons, AJAX would still work (this was a good thing).
However there is a key feature of JavaScript Objects that makes them so useful is that you can Prototype on them to add properties, methods, expando properties, or even subclasses. In addition it doesn't extend from Object, thus any prototyping done there won't be available on XHR, and none of the methods on XHR are exposed.
In IE6, the XHR Object was an ActiveX control only, in IE7 they added a "native" one, but it was just access to the XHR Object that didn't require ActiveX. In IE8 Beta 1 there are no changes, but In IE8 RTM, will we see a true native XMLHTTPRequest Object?
Example:
Lets say you wanted to improve the user experience when an AJAX request is sent to the server.
You might want to set a timeout that a response is expected by, and if it isn't cleared, automatically call an error handler.
You might want to queue up/discard duplicate requests if the browser has already sent a request in, and is waiting for a response.
You might want to add some debug capabilities to trace the progress of your AJAX Requests
Since an AJAX request might be very expensive on your server, you might want to add the ability to pass in a "cancellation" request, that is "tied" to the original request... this way if the user closes a window, or runs another query, you could send a quick "one-way" request to the server to cancel the first request.
In any of these cases, being able to store applicable info on the XHR object is ideal, and adding methods would enable callbacks to be self-contained.
<script type="text/javascript"> var myXHR = new XMLHttpRequest(); myXHR.lastAccess = null; myXHR.requestTimeout = 15000; myXHR.requestTimeoutHandler = myTimoutHandler; </script>
The above will fail in IE, since expando's and prototypes are not an option.
Want to see what Properties/Methods are exposed on XMLHttpRequest in your browser? Click the button to find out! (check in other browsers too)
(PS If you subscribe to this Blog via RSS/Atom, please try the button on the Blog site as we needed to update the sample several times to overcome some Blogger auto-line-break issues. - thanks)
Feb. 7,2009 - Added a new Tag called Broken By Design. It is applied to all reported bugs that the browser vendor has indicated that they have no intention of fixing this bug any time soon and is therefore broken "By Design".
Feb. 7,2009 - Updated as many bug reports as possible for Internet Explorer 8 (IE8) to reflect the status of IE8 RC1 since according to the IE Blog the RTM release is coming soon. If you want to know, click to see what has been fixed?
Drag/Right-Click and save to your Bookmarks
View generated source of a page in IE View Source
Show Rendering Mode for IE6/7 Render Mode
Show Rendering Mode for IE8 IE8 Render Mode
Show how many style tags a page has # style tags
Posts
