Closed Bug 34862 Opened 25 years ago Closed 25 years ago

content on NYTimes appears twice

Categories

(Core :: Layout: Tables, defect, P2)

Product:
Core
Component:
Layout: Tables
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: dbaron, Assigned: waterson)

References

(
URL
)

Details

(Keywords: testcase, Whiteboard: [nsbeta2+] FIX IN HAND)

Attachments

(5 files)

testcase
314 bytes, text/html
Details
variant #1
177 bytes, text/html
Details
variant #2
176 bytes, text/html
Details
even smaller test case.
125 bytes, patch
Details | Diff | Splinter Review
proposed fix; delete special siblings, crawl to outermost special during reframe
1.85 KB, patch
Details | Diff | Splinter Review
DESCRIPTION: Most/all of the content on the New York Times website appears twice (http://www.nytimes.com/ ). This is a regression that started in the past few weeks. STEPS TO REPRODUCE: * load http://www.nytimes.com/ ACTUAL RESULTS: * the page appears twice (second copy below first), sometimes with slightly strange layout (extra spacing before table columns) EXPECTED RESULTS: * page appears once DOES NOT WORK CORRECTLY ON: * Linux, mozilla, 2000-04-06-10-M15 WORKS CORRECTLY ON: * older builds. I think this was a regression sometime in the past few weeks. ADDITIONAL INFORMATION: When I load it in a debug build, I see the many assertions of the form: ###!!! ASSERTION: node in map twice: '(node->mContent != aNode->mContent) || ((node->mContent == nsnull) && (node->mStyle != aNode->mStyle))', file nsFrameManager.cpp, line 1786 ###!!! Break: at file nsFrameManager.cpp, line 1786 The content model looks correct, although large numbers of nodes have a refcount of 4 instead of the usual 3. Sorry for not filing this sooner after I noticed it...
Status: NEW → ASSIGNED
Target Milestone: --- → M16
Keywords: makingtest
Whiteboard: fenris.geo@yahoo.com
also occurs on win98, M15
Attached file testcase —
Keywords: makingtest → testcase
Whiteboard: fenris.geo@yahoo.com
Very good work on simplification. However, note that collapsing all the whitespace in the example you give makes the bug go away. Using letters instead of whitespace at certain places where the whitespace causes the bug causes interesting variants of the behavior.
*** Bug 37914 has been marked as a duplicate of this bug. ***
The content model is wrong. The <table></table> is not be terminated properly.
Assignee: karnaze → harishd
Status: ASSIGNED → NEW
The content model looks correct to me! Chris? docshell=01841620 html@03472078 refcount=3< head@03473FC8 refcount=2< > Text@034E0D00 refcount=3<\n\n> body@034E0BD8 refcount=3< icmeta@035172A8 url=http://incommon.nytimes.com/downtown/sitedefs/DEFnytimes .html _moz-userdefined= refcount=7< Text@035119A0 refcount=3<\n\n\n\n> table@037204F8 refcount=6< > Text@03720340 refcount=4<\n\n> nyt@03720228 _text= _moz-userdefined= refcount=8< Text@03720030 refcount=4<\n\n> table@03721F88 refcount=10< tbody@03721E78 refcount=4< tr@03721E08 refcount=4< td@03721D4C refcount=6< Text@03721C80 refcount=4<\n\n> Text@037206D0 refcount=6<Test\n\n> table@03721BE8 refcount=10< Comment@03721B20 refcount=2<!--here <td> must be before <tr>-- > tbody@037219E8 refcount=4< tr@03721928 refcount=4< td@037218BC refcount=6< Text@037217F0 refcount=4<\n\n> > > tr@03721788 refcount=4< > > > Text@03722FB0 refcount=4<\n\n> > > > > Text@03722E90 refcount=3<\n\n\n\n> > > > >
Your content model looks different than mine, and I had a Sat or Sun build. When I removed the <table></table>, there was no problem.
Could you attach the model that you see?
Note: The content-model I get seems to be correct...but I still see the double content. So, this ought to be a layout/table bug.
Nominating for beta2.
Status: NEW → ASSIGNED
Keywords: nsbeta2
Priority: P3 → P2
Here is the content-model from 05/09/00 build ( looks almost identical to the previous model ): docshell=018479E0 html@03093108 refcount=5< head@030930A8 refcount=4< > Text@03338630 refcount=3<\n> body@03338538 refcount=5< icmeta@0304FFC8 url=http://incommon.nytimes.com/downtown/sitedefs/DEFnytimes .html _moz-userdefined= refcount=8< Text@0304F9B0 refcount=3<\n\n> table@0304F918 refcount=6< > Text@0304F810 refcount=4<\n> nyt@0304F6F8 _text= _moz-userdefined= refcount=9< Text@0304F500 refcount=4<\n> table@0304F468 refcount=10< tbody@0304F3F8 refcount=4< tr@0304F388 refcount=4< td@0304F31C refcount=6< Text@0304F2A0 refcount=4<\n> Text@03054880 refcount=6<Test\n> table@0304F208 refcount=10< Comment@0304F190 refcount=2<!--here <td> must be before <tr>-- > tbody@0304F128 refcount=4< tr@0304EFB8 refcount=4< td@0304EF4C refcount=6< Text@0304EE80 refcount=4<\n> > > tr@0304EE18 refcount=4< > > > Text@03054BE0 refcount=4<\n> > > > > Text@03054AD0 refcount=4<\n\n> > > > > Over the Karnaze.
Assignee: harishd → karnaze
Status: ASSIGNED → NEW
The <icmeta> (which the parser moved into the <body>) is getting replicated inside the body; acutally it is the line containing the <icmeta> which gets replicated. I'm not sure if this is a content sink problem or a problem with the block constructing children. Vidur, can you take a look. If not please reassign to Nisheeth (who I guess is the content sink owner).
Assignee: karnaze → vidur
Putting on [nsbeta2+] radar for beta2 fix.
Whiteboard: [nsbeta2+]
*** Bug 40993 has been marked as a duplicate of this bug. ***
The problem seems to be fallout of the custom tags that the page includes. The tags are treated as inline content, but since they contain block content we fall into Kipp's block-inside-inline mess. Somewhere along the line there's a call to nsCSSFrameConstructor::ReframeContainingBlock, resulting in removal and recreation of the inline-containing-block frame tree. It seems like the removal process seems to just get the first inline frame, but not other frames that correspond to the custom content. Based on a conversation with buster, this seems like a DUP of bug 27211. Since this test case is still an interesting one to have around, I'm not actually DUPing the bug.
Assignee: vidur → nisheeth
Depends on: 27211
Chris, passing this on to you. This is already marked nsbeta2+ so you can checkin your inline-block fixes against this bug...
Assignee: nisheeth → waterson
Status: NEW → ASSIGNED
Target Milestone: M16 → M17
Something weird is happening here that has to involve the residual style code (that's the stuff that rotates the content model, right)? The key to causing the bustage is to have *two* inlines around the table, and then have some inline content after the table row, but before the table-close tag that gets promoted up to the inner span. Note that if I just put the content *in* the inner span, everything works fine. Here's the content model for the reduced test case: html@0x83573d0 refcount=3< head@0x8271288 refcount=2< > body@0x8224570 refcount=3< span@0x83526a0 refcount=7< span@0x83526d8 refcount=7< Text@0x843c608 refcount=3<y> table@0x8340618 refcount=10< tbody@0x8341350 refcount=4< tr@0x836f1f0 refcount=4< td@0x836f26c refcount=6< Text@0x83406c0 refcount=4<This should appear once.> > > > > > > > > Here's the content model if you promote the 'y' character out of the table by hand: html@0x8424848 refcount=3< head@0x84248b8 refcount=2< > body@0x8273fa0 refcount=3< span@0x83f41c8 refcount=5< span@0x83f4200 refcount=5< Text@0x83f4230 refcount=3<y> table@0x829ab88 refcount=6< tbody@0x83f40d8 refcount=3< tr@0x82513c8 refcount=3< td@0x825142c refcount=4< Text@0x83550f8 refcount=3<This should appear once.> > > > > > > > > They're the same! (Modulo refcounts -- maybe some leakage in the tree rotation code?) Kooky!
There were two problems: 1. We were not clobbering special sibling frames (actually, this code is not necessary to fix the bug, but it will cause unnecessary page bloat). 2. When reframing, we need to remember that block-in-inlines can be nested, and must crawl to the outermost "special" frame. nisheeth, could you review?
Whiteboard: [nsbeta2+] → [nsbeta2+] FIX IN HAND
r=buster. nicely done.
*** Bug 38698 has been marked as a duplicate of this bug. ***
fix checked in
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Using 7-14-08 build, verified fixed. Content appears once.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: