Matias Larsson Reporter
	Description • 21 years ago

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

	Frank Wein [:mcsmurf]
	Comment 1 • 21 years ago

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

	Mats Palmgren (inactive)
	Comment 2 • 21 years ago

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 ***

	David Baron :dbaron:
	Comment 3 • 21 years ago

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.

	Mats Palmgren (inactive)
	Comment 4 • 21 years ago

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

	Mats Palmgren (inactive)
	Comment 6 • 21 years ago

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

	Mats Palmgren (inactive)
	Comment 7 • 21 years ago

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.

	David Baron :dbaron:
	Comment 9 • 21 years ago

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

	David Baron :dbaron:
	Comment 10 • 21 years ago

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...

	Boris Zbarsky [:bzbarsky]
	Comment 11 • 21 years ago

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...

	David Baron :dbaron:
	Comment 12 • 21 years ago

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.

	Wayne Mery (:wsmwk)
	Comment 14 • 18 years ago

dbaron in comment #13
> Created an attachment (id=131916) [details]
> testcase for original problem

testcase WFM current trunk - list numbered 1., 2.

	Eli Friedman
	Comment 15 • 17 years ago

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

Same here... marking WORKSFORME.