build: 3/10/99 platform: checked on win95, win98, winNT, mac & linux expected results: when the LI type attribute is set to 'a' or 'i' the visual representation should be lower alpha and lower roman what I got: lower alpha renders as upper alpha and lower roman renders as upper roman here is the code: <dir> <li type="disc">directory list using the type attribute, item marker set to disc</li> <li type="circle">item marker set to circle</li> <li type="square">item marker set to square</li> <li type="1">item marker set to arabic</li> <li type="a">item marker set to lower alpha</li> <li type="A">item marker set to upper alpha</li> <li type="i">item marker set to lower roman</li> <li type="I">item marker set to upper roman</li> </dir>

Frank just whacked this code, so I suspect he broke it.

No, it's not my fault. It is already the wront style when it hit the nsBulletFrame code. I trace down the bug and find the problem in nsHTMLLIElement::StringToAttribute, that function call nsGenericHTMLElement::ParseEnumValue(aValue, kListItemTypeTable, aResult)) However, nsGenericHTMLElement::ParseEnumValue call aValue.EqualsIgnoreCase which will ignore the case. Therefore, it will match 'a' with {"A", NS_STYLE_LIST_STYLE_UPPER_ALPHA} and 'i' with {"I", NS_STYLE_LIST_UPPER_ROMAN} Reassign this to kipp since kipp is the last one touch the nsHTMLLIElement::StringToAttribute

*** Bug 3610 has been marked as a duplicate of this bug. ***

*** Bug 3606 has been marked as a duplicate of this bug. ***

Fixed. The attribute parsing logic was broken as frank pointed out.

[QA Assigning to self for verification on tomorrow's build.]

Re-opening after checking 3.19.99 builds using Apprunner: 1. Lowercase alpha characters draw properly on Win32 and Mac OS, but appear as uppercase alpha characters on Linux. 2. The arabic character (1) continues to appear as a circle. (This was mentioned in the bug subject, but may not have been mentioned in the actual bug report.) Thanks!

Okay, you caught me on that one. :-) HTML4 (not navigator 4) defines a new type of "1" which means "decimal". Now nglayout does that one too. Nice catch.

Thanks. (beppe's catch, really.) Anyway, verified fixed in 3.26.99 builds on Mac OS/Win32, and 3.24.99 build on Linux (Apprunner.) All attributes appear correctly cross-platform.