User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20030306 Camino/0.7 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030916 The strange thing is that IE6 has the exact same problem (is it *supposed* to work like this or have they "embraced and extended" some Mozilla code?) The example does work in IE5.5 and Safari (KHTML) Reproducible: Always Steps to Reproduce: 1. 2. 3. Actual Results: No numbers in front of LI Expected Results: Numbers in front of LI

This produces in a current cvs trunk build from today: On the screen I see 0. One 0. Two and when i copy&paste this (i can only mark the One and Two) i get: 1. One 2. Two

Please don't open a new bug report to make further comments on the same problem (bug 219714). To add comments on a bug, type text in "Additional Comments" and then press the "Commit" button. It's a bug and it's still a dupe of bug 4522. -> INVALID *** This bug has been marked as a duplicate of 4522 ***

What the original report was describing was different from the other bug. 'overflow: hidden' was recently changed to work differently, so that probably changed the behavior, but the problem likely still exists with whatever we call the value that used to be hidden.

My mistake, sorry. I still suspect the underlying cause is the same as for scroll/auto though.

OK, let's handle the overflow:hidden/auto/scroll problem in this bug then.

The problem is that we return early in |nsBlockFrame::RenumberLists| because |FrameStartsCounterScope(this)| returns false. It is false because |contentData.mCounterReset| is NULL in |nsRuleNode::ComputeContentData|. I think this is caused by the intermediary :-moz-scrolled-content style contexts.

I had wanted to leave the bug open to handle the problem with what's now -moz-hidden-unscrollable, but anyway...

Comment on attachment 131868 [details] [diff] [review] The fix sure, whatever magic works here. For bug 4522 we should probably rewrite the whole thing according to the CSS3 lists/counters model...

Comment on attachment 131868 [details] [diff] [review] The fix sr=bzbarsky; perhaps we really should reparent the style contexts as discussed elsewhere so that we don't have to list all this "inherit" stuff for -moz-scrolled-content...

Comment on attachment 131868 [details] [diff] [review] The fix Patch checked in. Leaving bug open for the original issue. But note that style context reparenting might not fix this problem.

dbaron in comment #13 > Created an attachment (id=131916) [details] > testcase for original problem testcase WFM current trunk - list numbered 1., 2.

(In reply to comment #14) > testcase WFM current trunk - list numbered 1., 2. Same here... marking WORKSFORME.