http://www.memoware.com will not load. Only the web page title appears in the title bar. This is with the 5/5/99 build

Well, here's a corner case for ya (if I'm not wrong ;). There is a table TD in the page that says basically: <tr><td colspan= bgcolor="#ffffff"></td></tr> Note the missing value for the colspan attribute. Setting this to '1' in the original page allows the entire page to lay out OK (modulo some unrelated image loading problems). The really tight part of the corner is that the subsequent bgcolor value _must_ be the strict form, i.e., quoted AND 'hashed' (#). Less strict forms (e.g. bgcolor=ffffff ) do not hang. (tested win95 1999050508 & 1999042808)

Updating QA Contact

Chris -- this is a legit bug. The question is, do you want to "fix" it by assigning your own default value, or should the parser. I'd argue it's yours, because the parser needs to be rather agnostic.

I'm not sure how I would give it a default value since it already has a bogus (very large) value. I can't distinguish between bogus values and legitimate values. The parser should probably just drop things like this (since they add nothing to the content model) and let the table code apply the defaults. Reassigning to Rick.

Chris -- let's not be hasty. The parser doesn't know anything about the value of attributes. Your point about your not knowing legit attribute values cannot be true. Let's discuss in person.

nsHTMLTableCellElement::StringToAttribute calls nsGenericHTMLElement::ParseValue which calls nsString::ToInteger. The problem is that ToInteger is not returning an error when it encounters the string 'bgcolor="#ffffff"'. Instead it returns a value of 1666665 which is not what I would expect for a radix of base 10. Although I'm using nsString1, I looked at nsString2::ToInteger and concluded that it doesn't fix this problem. I used the following html: <table border><tr><td colspan= bgcolor="#ffffff">foo</td></tr></table> Reassigning to Rick.

Stealing the bug!!

Works now!! The recent update to nsString::ToInteger() must have fixed this problem. Marking the bug fixed.

In the July 1 build, the page will load on all platforms.