Closed Bug 44709 Opened 26 years ago Closed 26 years ago

Mozilla can't count to 93+1 <ol><li>x94</ol>

Categories

(Core :: Layout, defect, P2)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: timeless, Assigned: waterson)

References

Details

(Whiteboard: FIXED IN THE TRUNK, BROKEN IN M17)

Attachments

(5 files)

Test Case; 1..500; {Hebrew} 1..500
10.74 KB, text/html
Details
testcase: 1 declaration per line ==> limit = 67
1.43 KB, text/html
Details
testcase: all declarations on the same line ==> limit = 100
1.22 KB, text/html
Details
fix
5.72 KB, patch
Details | Diff | Splinter Review
better fix
5.57 KB, patch
Details | Diff | Splinter Review
See test case. A warning for those of you who don't read hebrew, 14,15,16,17 are supposed to look unusual relative to the normal schema. For those who do, yes the letters are reversed, I think that's because we don't support bidi.
Pierre, can you please triage.
Assignee: clayton → pierre
It's an interesting and rather amusing problem... In fact the limit is not always 93: it depends on the number of lines in the HTML source. If all the lines contain only one "<LI>nn</LI>" declaration, the limit is 67. However if the lines contain more than one <LI> declaration, the limit is increased by 1 for every 3 declarations that are on the same line as other <LI> declarations. In the examples below, the numbers represent <LI> declarations. They show how the limit changes depending on how the declarations appear in the source: ----------------------- 1 2 ... 67 (max) ----------------------- 1 2 3 4 ... 68 (max) ----------------------- 1 2 3 4 5 6 ... 68 (max) ----------------------- 1 2 3 4 5 6 7 ... 68 (max) ----------------------- 1 2 3 4 5 6 7 8 9 10 ... 69 (max) ----------------------- What would be the absolute limit then? Considering that 67 individual lines can be combined into 16 lines of 4 declarations + 3 lines of 1 declaration, we would get 16 increments and the new limit would be 67 + 16 = 83. But then all these lines can be recombined too and that would increase again the limit. I'll spare you the complete demonstration but the absolute limit tends towards 67 + 67/3 + 67/3/3 + 67/3/3/3 + ... and if we take into account integer arithmetics, we find 67 + int(67/2) = 100 See the attached testcases for a confirmation of this result. When we have one line per declaration, the limit is 67. When we put all the declarations on a single line of source, the limit is 100. Sounds like a Parser bug to me. Reassigned to harishd.
Assignee: pierre → harishd
Component: HTML Element → Parser
OS: Windows 2000 → All
Hardware: PC → All
This can't be a parser bug. Parser doesn't set any such limit. This got to be a layout bug. CCing nisheeth and waterson.
Status: NEW → ASSIGNED
I agree that this isn't a parser bug. The line numbering logic sits in block/inline code starting at line 6940 in the RenumberLists() method. I don't think this is a beta 2 stopper, though, so Chris, do you want to grab this or should we put it in buster's pile?
List numbering is done in block-and-line layout code. I'll take a look.
Assignee: harishd → waterson
Status: ASSIGNED → NEW
Component: Parser → Layout
Status: NEW → ASSIGNED
Keywords: correctness, nsbeta3
Priority: P3 → P2
Target Milestone: --- → M18
*** Bug 46433 has been marked as a duplicate of this bug. ***
Attached patch fix — — Splinter Review
roc: can you take a look at these changes and let me know if they seem ok? The gist is this: 1. Replace the global gRenumberListDepthCounter with a stack variable that gets passed down through the list renumbering code. (I figure one less reason to worry about re-entrancy and threadsafety in the long run.) 2. Actually be sure to *decrement* it when we leave a recursion level. (That was the real bug!)
Whiteboard: FIX IN HAND
Looks OK. Why don't you just pass aDepth by value? Then you won't need to decrement it.
Wow. Duh.
Attached patch better fix — — Splinter Review
Does your patch fix bug 45768 too?
Unfortunately not.
fix checked in
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Hey, waterson, did you just fix bug 42941 (assigned to buster)?
*** Bug 42941 has been marked as a duplicate of this bug. ***
*** Bug 46969 has been marked as a duplicate of this bug. ***
Shouldn't this fix be transferred to the branch? This would mean a little less bug reports for beta2... :) There are already three dupes here.
Whiteboard: FIX IN HAND → FIXED IN THE TRUNK, BROKEN IN M17
*** Bug 48062 has been marked as a duplicate of this bug. ***
Bug still there in M17 with WinNT4 on http://blanalex.dyndns.org and it's worst now, it doesn't render the whole page, it stops after 73 <LI> elements inside a <OL>.
oops, after reloading the page twice, it renders completely, must be a local proxy problem but the <LI> bug is still there, though
I think the fix is in the M18 trunk, not the M17 branch.
Fixed in the Aug 24 build.
Status: RESOLVED → VERIFIED
*** Bug 52430 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: