53690 - Page content not shown

Status: VERIFIED FIXED

(Core :: Layout, defect, P2)

Description

[Bernd]

WinNT 2000092120

1. Go to the URL

2. Select a company ( I selected Licel GbR)	

3. No company description visible (Works with Nav4.6)

4. Press the back button. The companies list hash vanished.

desired action: Content should be shown always.

Comment 1

[Keyser Sose]

I can't even see the company dialog box now. This leads me to believe there is
something wrong in Mozilla rather then the webcoding. Though i could be wrong.
This is javascript btw.
Platform: PC
OS: Windows 98
Build: 2000092608

Comment 2

[karnaze (gone)]

Reassigning to jst. This sounds a bit like 54571.

Comment 3

[Johnny Stenback (:jst)]

Looks like a parser bug, reassigning to Harish for futher investigation.

Comment 4

[Bernd]

This seems to by dynamic generated content There are some Lotus ... comments in
 the source.

Comment 5

[harishd]

Attachment: Reduced case..

Comment 6

[harishd]

Chris, I don't think this is parser. Looks like table to me.

Here is the content model for the testcase:
docshell=01FADD50
html@0334C948 refcount=6<
  head@0334C858 refcount=2<
  >
  Text@0338A0C0 refcount=3<\n\n\n>
  body@0338BED8 refcount=3<
    Text@033C2100 refcount=3<\n\n>
    table@033C4F78 border=0 cellpadding=0 cellspacing=0 bgcolor=#ffffff refcount
=7<
      Text@033C4B00 refcount=2<\n\n >
      tbody@033C49D8 refcount=3<
        tr@033C48D8 refcount=3<
          Text@033C47A0 refcount=2<\n  >
          td@033C467C refcount=4<
            Text@033C4540 refcount=3<\n   >
            table@033C44A8 border=0 cellpadding=0 cellspacing=0 refcount=6<
              Text@033C4200 refcount=2<\n    >
              tbody@033C4158 refcount=3<
                tr@033C40E8 refcount=3<
                  Text@033C5EF0 refcount=2<\n    >
                  td@033C5E8C width=7 bgcolor=#000000 refcount=4<
                    Text@033C5A30 refcount=3<\n   \n>
                    script@033C57B8 language=JavaScript refcount=2<
                      Text@033C53F0 refcount=2<\n         document.write('<form
method=post name = "DominoForm1" action="' + document.forms[1].action + '">');
         \n>
                    >
                    Text@033D3040 refcount=3<\n   \n        >
                  >
                  Text@033D3410 refcount=3<\n      >
                >
                Text@033D4040 refcount=3<\n\n      >
              >
            >
            Text@033D4E50 refcount=3<\n     >
          >
          Text@033D4D20 refcount=3<\n     >
          td@033D4C7C bgcolor=#ffffff valign=Top refcount=4<
            Text@033D4680 refcount=3<hi there\n    \n>
          >
        >
      >
    >
  >
>

The text "hi there" does get into the content model but fails to render.

Reassigning to [e-mail]

Comment 7

[harishd]

Attachment: Reduced case..

Comment 8

[harishd]

Hmmmm... for some reason the attachment loads correctly. I bet this is some
whitespace issue inside TABLE. Chris, please try saving the attachemnt and open
it up in mozilla.

Comment 9

[Bernd Mielke]

I nominate this bug for rtm because I hit this bug several times on theire
web-pages. I have to switch to Nav4.6 to see the pages. In the T&M world they
are the address No. 1. Thats not a fancy mp3 page, this is real business that
cannot be done with the browser today.

Comment 10

[Bernd Mielke]

I hoped kmclusk's checkin (2000-10-16 22.05) would improve the picture, this not
the case. The testcase also "works"  with pressing the back and forward button.

Comment 11

[karnaze (gone)]

Buster, during the construction of the cell containing "hi there" in 
nsCSSFrameConstructor::ConstructTableCellFrame the line 
aNewCellInnerFrame->SetInitialChildList(aPresContext, nsnull, 
childItems.childList); is not setting mFrames and consequently the "hi there" is 
not showing up. childItems.childList does contain a valid text frame with the 
correct content.

This bug sounds similar to another one that I reassigned to you recently, but I 
can't remember the number.

Comment 12

[selmer (gone)]

Marking [rtm need info] because there is activity in the bug.  Time is running 
out, is it time to let this go rtm-?  Is this a top100 site?  Is there an 
argument that a high percentage of sites will have this problem?

Comment 13

[Bernd Mielke]

I do not know whether this a top100 site,  but for me this is dogfood because 
every time I have to check something there, I have to use Nav46. I mailed to 
them the bugID, so may be they can better explain why it is important.

Comment 14

[buster]

Attachment: a more complete testcase

Comment 15

[buster]

the test cases attached on 10/02/00 work for me, but the one I just attached
10/26/00 09:16 shows the broken behavior.  It looks like the text frame itself
is corrupted.  The text content node has the write text data, but the frame
thinks it's 0-length.

Comment 16

[buster]

Chris:  I'm not seeing the behavior you talk about in your 2000-10-18 17:19 
comment at all.  The test cases you attached work fine for me.  But I do have a 
test case (attached, will attach an even simpler one in a second) that breaks.
What I see happening in this test case is this:
1. The TR gets an initial reflow, and passes that down to the first cell.  The 
second cell doesn't exist yet.
2. The TR gets an incremental reflow targeted down at the first cell, and passes 
that down correctly.
3. The TR then gets a resize reflow, and at this point the second cell exists 
and is hooked up as the next sibling of the first cell.
4. In nsTableRowFrame::ResizeReflow(), aDirtyOnly is 0 at this point.
5. There is some odd logic using aDirtyOnly that I don't understand, but 
basically it boils down to the TR calculating a 0 available width for the second 
cell.  This causes the check:
 if ((aReflowState.reflowState.availableHeight != NS_UNCONSTRAINEDSIZE) ||
     (availWidth != ((nsTableCellFrame *)kidFrame)->GetPriorAvailWidth()) ||
     (nsnull != kidNextInFlow))
to fail.  So we skip the reflow to the second cell, and use the cached "prior" 
values for it's width and height, which are 0.
6. The TR then gets the incremental reflow telling it that the second cell has 
been added.  This eventually calls nsTableRowFrame::ResizeReflow() with 
aDirtyOnly=1.  Neither of the cells is marked dirty, so again we do not reflow 
the second cell.
7. We are now doomed.  During all subsequent ResizeReflows, the TR calculates a 
0 availWidth for the second cell, which matches it's cached "prior" width.  So 
we never reflow it.

I think the fix for this is to change this line:
  if (aDirtyOnly && (frameState & NS_FRAME_FIRST_REFLOW)) {
to simply be
  if (frameState & NS_FRAME_FIRST_REFLOW) {

I think that if a cell has never been reflowed, it needs to get it's initial 
reflow at unconstrained width regardless of what type of reflow was originally 
requested.

Comment 17

[buster]

Attachment: same test case as above, but without the nested table. Makes debugging much easier.

Comment 18

[buster]

Attachment: proposed fix

Comment 19

[Bernd]

Steve, thank's a lot. This patch saves my day. Works great on the whole site of
my original posting. I hope you will get all the small letters (a r sr) for it. 

Comment 20

[buster]

chris k. and I talked about this patch at length and feel comfortable with it.
More testing is needed today, but I think we should get it into the branch and
let it bake there, then argue for rtm inclusion.
k, please r=
w, please a=

Comment 21

[karnaze (gone)]

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

Comment 22

[Chris Waterson]

Nice! You should prolly fix the "// If it's a dirty frame, ..." comment at line
~943, but other than that, a=waterson

Comment 23

[Phil Peterson]

PDT marking [rtm need info] since only one reviewer available so far.

Comment 24

[buster]

phil: not so. karnaze added his r= to the whiteboard already, and waterson has
already given his a=.  Does this make it ++?

Comment 25

[Phil Peterson]

Sorry Steve. This bug is in candidate limbo.  We will reconsider this fix once
we have a candidate in hand, but we can't take this fix before then.

Comment 26

[buster]

fix checked into trunk

Comment 27

[selmer (gone)]

PDT marking [rtm++]. This bug is now out of limbo and approved for checkin to
the branch. Please check in ASAP.

Comment 28

[buster]

fix checked into branch

Comment 29

[harishd]

The above URL and all the attachements display content. Also, bug 55736 ( dup )
is fixed. Verified on WinNT, 2000-10-31-13-MN6 ( branch ).

Marking VERIFIED.

Comment 30

[harishd]

Looks like we are not supposed to mark verified unless it's maked verified in
both branch & trunk.

Brach - 2000-10-31-14-MN6 - verified.

Comment 31

[harishd]

Added vtrunk to the keyword.

Comment 32

[karnaze (gone)]

The fix regressed printing. Bug 58665 has a test case.

Comment 33

[karnaze (gone)]

Attachment: patch to fix printing regression

Comment 34

[karnaze (gone)]

I think we should fight for PDT to approve the revised patch, because it is very 
safe, and it is hard to tell how many pages will not print coherently due to the 
1st patch. I'm planning to call or email PDT about this bug, but I guess we need 
an a= and r= for the revised patch. I'm also reassigning the bug to myself.

Comment 35

[buster]

r=buster.  waterson, the sr honors are all yours.

Comment 36

[Jim Roskind]

Pushing back to rtm need info.  You need all reviews in hand to go to a plus.  

Understand that it may be too late to handle this :-(

Comment 37

[karnaze (gone)]

Marking rtm+. Buster agreed to change his r= to a=. This is a fairly serious 
printing regression and the revised fix touches only the same lines as the 
original fix.

Comment 38

[selmer (gone)]

rtm++, please check in on the branch ASAP.

Comment 39

[karnaze (gone)]

Fixed.

Comment 40

[Chris Petersen]

Fixed in the Nov 3 branch build.

Comment 41

[James Lariviere]

John Morrison commented in bug report 59278 that a regression (cell contents
overflowing) and also reported in 59252 was caused by the patch for this bug?

Comment 42

[Asa Dotzler [:asa]]

Verified Fixed on Mozilla trunk builds
linux 122810 RedHat 6.2
win32 122805 NT 4
mac 122808 Mac OS9
Setting bug to Verified and removing vtrunk keyword