This site heavily relies on bug reports created by its readers. Anyone can report a bug and be published.
Main navigation:
Search reports by browser:
This is the monthly Bug Reports archive for December 2004.
Permalink
| General
Reported on 27 December 2004
Merry Christmas and a happy new year to all of you.
The Bug Report is on holiday for the last week of 2004, so there will be no new bugs during that time. The first week of the new year will feature some golden oldies I discovered ages ago but haven't yet ported to the Bug Report. These bugs aren't terribly exciting, but they have to be present in the system.
Regular bug reporting will resume on Monday 10 January. There are a few beauties waiting for publication; and I predict browsers will continue to be unpredictable in the new year.
In the mean time, feel free to send in new bug reports, even though it may take a few extra days before I'm able to study them and to allocate them a publication slot.
Permalink
| Mozilla
| 6 comments
Reported on 24 December 2004
When a floating box appears directly after a header in Mozilla, the very first line of text after the float doesn't obey the float but is rendered right through the floating box.
The first floating box on a page is never affected by this bug, though.
Test page. Workaround is not included.
Reported by ppk.
Permalink
| Opera
| 5 comments
Reported on 23 December 2004
Opera doesn't accept a cursor: pointer for an input type="submit".
Test page. Workaround is not included.
Reported by ppk.
Permalink
| Explorer 5-6 Windows, Explorer 7 beta 2, Explorer Mac
| 3 comments
Reported on 22 December 2004
Explorer positions a background-image underneath the border of the element. Therefore it's impossible to get the position of a background image in an element with a border correct in all browsers.
Test page. Workaround is not included.
Reported by ppk.
Permalink
| Explorer 5-6 Windows, Explorer Mac
| 1 comments
Reported on 20 December 2004
When using multiple class names for an element, Explorer will ignore all but the last of class names:
element.class1.class2 { }
Explorer completely ignores the class1 selector and happily applies the rule to an element that has only class2 set.
Test page Workaround is not included
Reported by: Tino Zijdel.
Permalink
| Explorer Mac, Mozilla, Opera
| 2 comments
Reported on 17 December 2004
Mozilla and Opera split up one huge text node into several smaller text nodes. Explorer Mac acts weirdly.
Maximum text node sizes:
Test page. Workaround is not included.
Reported by ppk.
Permalink
| Opera, Safari
| 4 comments
Reported on 16 December 2004
Anchor (or "#name")links don't work when the target anchor is inside an overflowing element.
Solved in Opera 7.60p3
Test page Workaround is not included
Reported by: Sander Grendelman.
Permalink
| Explorer 5-6 Windows
| 2 comments
Reported on 15 December 2004
In IE with SP2 if you a few a few anchor tags for a menu that have some vertical distance from each other (by using the bottom margin) and on hover want them to change background color, you are in for a nice surprise (removing the margin of the anchor 2 places behind it ..)
Test page Workaround is not included
Reported by: Petrioli Gabriel.
Permalink
| Safari
| 4 comments
Reported on 14 December 2004
When more than one animated GIF features on a page, Safari sometimes does not play the animation.
Test page. Workaround is not included.
Reported by Nic Rodgers.
Permalink
| Explorer 5-6 Windows
| 2 comments
Reported on 13 December 2004
<A> elements with a background image have a problem. It is in effect (as far as I can see):
display:blockposition:relativeBug fix: The element must get position:relative, which creates problems for IE5.0, as it then ignores padding-left on the element.
Test page Workaround is included
Reported by: Jesper Rønn-Jensen.
Permalink
| General
| 7 comments
Reported on 10 December 2004
Some bug test pages I receive don't work in all browsers. For instance, I've received one application/xhtml+xml-mimed page, and one page that mysteriously doesn't work in Explorer Windows (though in both cases the bug report is about Opera).
Are these pages good bug test pages?
Obviously, there are test pages that cannot work in all browsers. If the bug applies to, say, the handling of position: fixed the test page will never work in certain browsers. These cases are clear.
In other cases, though, the question is more muddled. One could argue that any bug report test page must work in as many browsers as possible, since it's supposed to show that one browser's behaviour is different than the others'. Therefore, if any browser cannot use the test page even when it supports the styles or script in question, the bug page is flawed.
Besides, when I receive a bug report I run the test in every browser. Some bug reporters don't have access to Mac browsers, so it's particularly worth checking if the report also applies to Explorer Mac and Safari. When a page doesn't work in all browsers, though, I can't use this simple and efficient check.
On the other hand it could be argued that any page that allows us to verify the bug is good enough. After all, the page fulfills its purpose by allowing us to test the bug in the relevant browser.
At the moment I can't decide what to do. So I'd like your opinion: should a bug report test page work in as many browsers as possible? Should I refuse test pages that don't work in a browser they could work in? Or are bug reporters free to do what they like, as long as the bug can be verified in the relevant browser?
Permalink
| Explorer 5-6 Windows, Safari
| 2 comments
Reported on 10 December 2004
Setting an inline border style (element.style.border) works in all browsers. Removing it to allow the normal border styles to return, however, is tricky in Explorer Windows and impossible in Safari.
Test page. Workaround is included.
Reported by ppk.
Permalink
| Explorer Mac, Mozilla
| 0 comments
Reported on 9 December 2004
Mozilla doesn't honour a position: relative on a table, which can therefore never serve as a container for absolutely positioned elements. This is a deliberate choice, and not a bug, oddly.
Test page. Workaround is not included.
On the other hand, Explorer Mac behaves as if every table has a position: relative. It always positions absolute layers in the table relative to the table, even if they should be positioned relative to the browser window.
Test page. Workaround is not included.
Reported by ppk.
Permalink
| Explorer 5-6 Windows
| 0 comments
Reported on 8 December 2004
Setting up a row of floats in Explorer 6 can lead to a plethora of erratic behavior, namely duplicate characters; in this bug report, I go into detail on some pure-CSS triggers which can make these extra characters appear, examples on how the bug is triggered, and different ways to combat it.
Note that these bugs are not caused by comments in your XHTML, as is the well known original Duplicate Characters Bug.
Test page Workaround is included
Reported by: Agent EQzE.
Permalink
| Opera
| 3 comments
Reported on 7 December 2004
<br style="clear: both"/> is not obeyed following some <a>-tags that have been floated left. The following <div> with the heading is displayed to the right of the floated elements instead of being displayed below them.
NOTE the test page is served using application/xhtml+xml and thus won't show in IE.
Test page Workaround is not included
Reported by: Bjarne Mathiesen.
Permalink
| Explorer 5-6 Windows, Explorer 7 beta 2
| 0 comments
Reported on 6 December 2004
When a floated box does not have non-floated content alongside it that extends the full height of the float (including its vertical margin), the next 'cleared' div after the float has a top padding that is twice what it ought to be (in IE5.5 and 6).
Test page Workaround is included
Reported by: Luke Plant.
Permalink
| Explorer Mac
| 0 comments
Reported on 3 December 2004
Absolutely positioned elements have a secret right and bottom margin of 15px. When you place such an element flush right or bottom, an unwanted scrollbar may appear.
Possibly the margin is the space reserved for the element's scroll bar.
Test page. Workaround is included.
Reported by ppk.
Permalink
| Safari
| 0 comments
Reported on 2 December 2004
When resizing a window vertically through resizeBy, Safari seems to move the entire window instead.
Test page. Workaround is not included.
Reported by ppk.
Permalink
| Mozilla
| 1 comments
Reported on 1 December 2004
When seting class names dynamically through JavaScript, Mozilla doesn't apply the first-letter and first-line styles.
Test page. Workaround is not included.
Reported by ppk.
See the November 2004 archive.