Affects: IE6, IE7
Fixed In: IE8 Beta 2
The hasAttributes() method is available on the Node element in DOM 2 (W3C).
Test:
Known Workarounds: One. Test using a try/catch for the specific attribute you care about.
Related Issues: None.
Submit a bug
Sunday, August 31, 2008
bug 215 - no hasAttributes() support in IE6, IE7
Issue: #215
Affects: IE6, IE7
Fixed In: IE8 Beta 2
The hasAttributes() method is available on the Node element in DOM 2 (W3C).
Test:
Known Workarounds: One. Test using a try/catch for the specific attribute you care about.
Related Issues: None.
Bug/Site Feedback |
Submit a bug
Affects: IE6, IE7
Fixed In: IE8 Beta 2
The hasAttributes() method is available on the Node element in DOM 2 (W3C).
Test:
Known Workarounds: One. Test using a try/catch for the specific attribute you care about.
Related Issues: None.
Submit a bug
Thursday, August 28, 2008
Browser Life Statuses
Browser Life Status:
Many will argue what set of browsers should be supported for a given site or application but there isn't a perfect answer. Its a trade off between accepting a wide range of users, browsers, and platforms vs. the development time & cost needed to support them.
Eventually though, you need to kick certain browsers to the curb. You reach the threshold where it simply isn't worth your time to support them.
Deciding when to drop support is tricky what rules do you apply?
1.) We only support the last 2 official versions of modern browsers?
2.) We only support Mac/Windows?
3.) Only browsers less than 2 years old?
One of the tools you'll need to decide, is some stats about the browsers themselves. Just how old is IE6? What about Firefox 1.0?
Well hopefully this will help out. Its a "live" list of browsers age color coded to visually indicate just how old a given browser is*.
(Update: Bloggers options for inserting JavaScript and CSS into a post are limited. We are looking to host this externally to ensure 100% uptime.)
* Where exact release dates were not known, the 1st of the month they were released was used.
We have certainly come a long way! We'll be sure to add new browsers when they are officially released and expand this to include some of the less popular ones.
Bug/Site Feedback |
Submit a bug
Many will argue what set of browsers should be supported for a given site or application but there isn't a perfect answer. Its a trade off between accepting a wide range of users, browsers, and platforms vs. the development time & cost needed to support them.
Eventually though, you need to kick certain browsers to the curb. You reach the threshold where it simply isn't worth your time to support them.
Deciding when to drop support is tricky what rules do you apply?
1.) We only support the last 2 official versions of modern browsers?
2.) We only support Mac/Windows?
3.) Only browsers less than 2 years old?
One of the tools you'll need to decide, is some stats about the browsers themselves. Just how old is IE6? What about Firefox 1.0?
Well hopefully this will help out. Its a "live" list of browsers age color coded to visually indicate just how old a given browser is*.
(Update: Bloggers options for inserting JavaScript and CSS into a post are limited. We are looking to host this externally to ensure 100% uptime.)
* Where exact release dates were not known, the 1st of the month they were released was used.
We have certainly come a long way! We'll be sure to add new browsers when they are officially released and expand this to include some of the less popular ones.
Submit a bug
Wednesday, August 27, 2008
bug 342 - Connecting... in IE7 / IE8 takes F-O-R-E-V-E-R
Issue: #342
Affects: IE7, IE8
Update: It is well known that addon/extensions slow down IE. Disable any that are not required. In particular, MS Research is very slow and not needed.
Note: IE is still extremely slow after disabling addons, but the speed will improve.
Status: Microsoft has confirmed this will NOT be fixed in IE8 RTM
Normally the bugs posted on here deal with the content served up to the browser in HTML, CSS & JavaScript.
However Today's bug is about opening a new Tab in IE7/IE8, and the fact that it takes a V-E-R-Y long time (read:unacceptable), while "Connecting..."
Now we would be okay with the slowness if it were downloading something complex like the Digg or Slashdot, front page... but this happens opening the "about:blank" page!
For those unaware, the HTML code for the "about:blank" page is listed below.
"about:blank" HTML:
(That's it folks! No JavaScript!, No CSS!, No Head!, No Body!, Nada, Zip, Zilch!)
What is really frustrating with this, is that it seems to lock up resources while loading thus making it very hard to do anything else while the new tab is loading.
The final blow comes when you are opening the new tab, to paste in a new URL. If you paste it in reasonably quickly, it will kind of get there, but then get overwritten with "about:blank"... and IE can't load the page so you need to re-select the URL and re-paste it in to get to the site you wanted.
Usability is apparently one of the key objectives in IE8, so lets hope that this gets fixed before IE goes RTM. ;-)
Addition: By default in IE8 Beta 2, the "about:Tabs" page appears for a new tab, with a collection of additional items/options. This page is very slow also, but setting it to use "about:blank" doesn't speed things up.
Known Workarounds: None.
Related Issues: None.
Bug/Site Feedback |
Submit a bug
Affects: IE7, IE8
Update: It is well known that addon/extensions slow down IE. Disable any that are not required. In particular, MS Research is very slow and not needed.
Note: IE is still extremely slow after disabling addons, but the speed will improve.
Status: Microsoft has confirmed this will NOT be fixed in IE8 RTM
Normally the bugs posted on here deal with the content served up to the browser in HTML, CSS & JavaScript.
However Today's bug is about opening a new Tab in IE7/IE8, and the fact that it takes a V-E-R-Y long time (read:unacceptable), while "Connecting..."
Now we would be okay with the slowness if it were downloading something complex like the Digg or Slashdot, front page... but this happens opening the "about:blank" page!
For those unaware, the HTML code for the "about:blank" page is listed below.
"about:blank" HTML:
<html></html>
(That's it folks! No JavaScript!, No CSS!, No Head!, No Body!, Nada, Zip, Zilch!)
What is really frustrating with this, is that it seems to lock up resources while loading thus making it very hard to do anything else while the new tab is loading.
The final blow comes when you are opening the new tab, to paste in a new URL. If you paste it in reasonably quickly, it will kind of get there, but then get overwritten with "about:blank"... and IE can't load the page so you need to re-select the URL and re-paste it in to get to the site you wanted.
Usability is apparently one of the key objectives in IE8, so lets hope that this gets fixed before IE goes RTM. ;-)
Addition: By default in IE8 Beta 2, the "about:Tabs" page appears for a new tab, with a collection of additional items/options. This page is very slow also, but setting it to use "about:blank" doesn't speed things up.
Known Workarounds: None.
Related Issues: None.
Submit a bug
Tuesday, August 5, 2008
bug 404 - Operation Aborted in IE
Issue: #404
Affects: IE6, IE7, IE8
MSDN KB#: 927917
This issue in IE has a deep explanation over on the IE Blog in a post titled: What Happened to Operation Aborted. It is believed to be the source of pain that Sitemeter users were suffering from this past week in IE7.
To sum up, it happens when you use an inline script tag in your page to modify the contents of any of the un-closed ancestor tags of the script tag (excluding the direct parent).
In IE8 they are attempting to fix this, however thus far only the modal error message has been removed, and the page no longer goes blank.
Exact Conditions:
Example:
The problem is, this is a very easy scenario to encounter, and to make it worse... if the bug is triggered in an iframe (*cough*, *cough* 3rd party ads anyone?) it affects the parent document, not just the iframe.
To make it worse the dialog is modal, requiring the user to interact with it to close it and when you close it IE navigates to an error page not letting you have a chance to debug it.
Known Workarounds: One. Do whatever you need to do to avoid this scenario. E.g. execute the script after the tag in question has closed, or only alter the script tags immediate parent.
Related Issues: None.
Bug/Site Feedback |
Submit a bug
Affects: IE6, IE7, IE8
MSDN KB#: 927917
This issue in IE has a deep explanation over on the IE Blog in a post titled: What Happened to Operation Aborted. It is believed to be the source of pain that Sitemeter users were suffering from this past week in IE7.
To sum up, it happens when you use an inline script tag in your page to modify the contents of any of the un-closed ancestor tags of the script tag (excluding the direct parent).
In IE8 they are attempting to fix this, however thus far only the modal error message has been removed, and the page no longer goes blank.
Exact Conditions:
- The HTML file is being parsed
- script is executing
- The executing script attempts to (add or remove) an element from an unclosed ancestor in the markup tree (excluding immediate parent of the script element)
Example:
<html>
<body>
<div>
<script>
var newDiv = document.createElement('div');
document.body.appendChild(newDiv);
</script>
</div>
</body>
</html>
The problem is, this is a very easy scenario to encounter, and to make it worse... if the bug is triggered in an iframe (*cough*, *cough* 3rd party ads anyone?) it affects the parent document, not just the iframe.
To make it worse the dialog is modal, requiring the user to interact with it to close it and when you close it IE navigates to an error page not letting you have a chance to debug it.
Known Workarounds: One. Do whatever you need to do to avoid this scenario. E.g. execute the script after the tag in question has closed, or only alter the script tags immediate parent.
Related Issues: None.
Submit a bug
Saturday, August 2, 2008
Web Bug Track - A Brief Update
The status quo
Well, here we are 1 year later! It was a year ago we first welcomed you to this "bug blog". It started as just a simple concept... a way to track web bugs in HTML, JavaScript, DOM, CSS, etc. in the world wide web of Web Browsers.
The landscape has changed significantly since starting this blog. Mozilla released Firefox 3, a worthy successor to the hugely popular Firefox 2, even setting a Guinness World Record in the process. Opera released the latest update to their browser, squashing a several pesky bugs and improving their Web Standards by drifting away from legacy IE-spoofing and being the first to pass the ACID3 test! The KDE folks released Konqueror 4.0, boosting speed and cleaning up rendering issues they had. Safari has been making leaps and bounds with WebKit in terms of supporting advanced CSS3 properties and being the second browser to pass the ACID3 test. Finally Microsoft re-opened their bug tracking tool "IE Feedback" on the Connect site when IE8 Beta 1 was released to developers. This was a welcome change as there was much frustration when Microsoft decided to close it (and remove all entries) after IE7 went RTM. We hope that it will remain open when IE8 goes RTM later this year, however if it doesn't you can rest assured that Web Bug Track isn't going anywhere!.
Alas when we began this blog, there was a simple concept we wanted to fulfill. Allow Web Developers and Designers a source to track bugs (regardless of which Browser / Vendor they were for), provide clear workarounds where known to get around bugs and lastly allow the community an opportunity to share their bug findings, so that we can all benefit.
So here we are now getting 1,000s upon 1,000s of hits every month from Developers looking for workarounds, or just looking to find out which versions of a browser are affected by a bug, or which HTML elements have issues in which browser. I can tell you that from the stats and the praise I've received thus far, I feel overwhelmingly satisfied that this experiment has been a huge success... and obviously filled a need in the "Developers Toolbox" of tips and tricks.
So where to now?
Good question! There's a few changes coming up that I think will make things that much better.
The Recent Updates Section will allow returning visitors to easily spot changes to bugs / workarounds. An addition to Google's Knol Reference Pages allows direct linking/searching of bugs here on Web Bug Track by Browser, HTML Element Type, JavaScript Method or Property. There will be a few more additions too, but I'll keep those as a surprise for now. ;-)
Thanks for making Web Bug Track a success! I hope you've enjoyed reading it as much as I've enjoyed putting it all together.
Cheers!
Bug/Site Feedback |
Submit a bug
Well, here we are 1 year later! It was a year ago we first welcomed you to this "bug blog". It started as just a simple concept... a way to track web bugs in HTML, JavaScript, DOM, CSS, etc. in the world wide web of Web Browsers.
The landscape has changed significantly since starting this blog. Mozilla released Firefox 3, a worthy successor to the hugely popular Firefox 2, even setting a Guinness World Record in the process. Opera released the latest update to their browser, squashing a several pesky bugs and improving their Web Standards by drifting away from legacy IE-spoofing and being the first to pass the ACID3 test! The KDE folks released Konqueror 4.0, boosting speed and cleaning up rendering issues they had. Safari has been making leaps and bounds with WebKit in terms of supporting advanced CSS3 properties and being the second browser to pass the ACID3 test. Finally Microsoft re-opened their bug tracking tool "IE Feedback" on the Connect site when IE8 Beta 1 was released to developers. This was a welcome change as there was much frustration when Microsoft decided to close it (and remove all entries) after IE7 went RTM. We hope that it will remain open when IE8 goes RTM later this year, however if it doesn't you can rest assured that Web Bug Track isn't going anywhere!.
Alas when we began this blog, there was a simple concept we wanted to fulfill. Allow Web Developers and Designers a source to track bugs (regardless of which Browser / Vendor they were for), provide clear workarounds where known to get around bugs and lastly allow the community an opportunity to share their bug findings, so that we can all benefit.
So here we are now getting 1,000s upon 1,000s of hits every month from Developers looking for workarounds, or just looking to find out which versions of a browser are affected by a bug, or which HTML elements have issues in which browser. I can tell you that from the stats and the praise I've received thus far, I feel overwhelmingly satisfied that this experiment has been a huge success... and obviously filled a need in the "Developers Toolbox" of tips and tricks.
So where to now?
Good question! There's a few changes coming up that I think will make things that much better.
- Recent Updates Section
- Knol Reference Page - Web Browser Bugs
The Recent Updates Section will allow returning visitors to easily spot changes to bugs / workarounds. An addition to Google's Knol Reference Pages allows direct linking/searching of bugs here on Web Bug Track by Browser, HTML Element Type, JavaScript Method or Property. There will be a few more additions too, but I'll keep those as a surprise for now. ;-)
Thanks for making Web Bug Track a success! I hope you've enjoyed reading it as much as I've enjoyed putting it all together.
Cheers!
Submit a bug
Subscribe to:
Posts (Atom)
Posts
