31644 - Left side of etrade page rendered repeatedly

Status: VERIFIED FIXED

(Core :: Layout, defect, P1)

Description

[eford]

The left side of ETrade's pages is often rendered multiple times.  Sometimes
only three, other times more.  Even worse, when I place the cursor over a link,
links on the copies further down get highlighted.  Sometimes it's the same link
on each copy, but other times it's a different link further down.

Comment 1

[Richard Zach]

Similar to things reported in bug 28553; mouseovers recreate table cells. 
Confirmed in Linux build 2000.03.13.03.  -> Layout, cc: buster.  

Comment 2

[troy]

*** This bug has been marked as a duplicate of 28553 ***

Comment 3

[Richard Zach]

Reopening this one as per buster's comment in bug 28553.  Please compare to bug
30007, bug 31435, and bug 32052.

Comment 4

[troy]

If Buster wants it reopened, then it's getting reassigned to him...

Comment 5

[Phil Peterson]

PDT-

Comment 6

[chris hofmann]

wondering if this is a regression from the 28553 fix.
when did it appear?  if that fix was under pref control
still we would have an easy way to find out.
looks pretty ugly and is likely to genrate lots of
bug traffic in the beta.

Comment 7

[buster]

I verified that this isn't a result of the fix for 28553.  It's possibly related 
to the same bad code, but really it's a separate problem entirely.

Comment 8

[buster]

major problem, needs to be addressed soon.  could REALLY use a reduced test case 
for this one.

Comment 9

[Richard Zach]

Attachment: reduced testcase

Comment 10

[Richard Zach]

Attached a reduced testcase: Mouseover the link to see stuff between
<SPAN..</SPAN> multiplying.

<FONT>
<SPAN>
<P></P>
<A HREF="test">Mouseover here to see link text multiplying</A>
</SPAN>

The FONT tag can be replaced with, e.g., <B>. The SPAN seems to be necessary,
bug goes away when replaced by DIV, P, or PRE. 

The <P></P> can also be replaced by <LI></LI> or <DIV></DIV>.

See also this testcase for bug 30007, which results in similar behavior
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=6324

<font><nobr>
<table></table>
<a href="xxx">xxx</a>
</nobr></font>

Comment 11

[buster]

Great test case, zach.

This is similar to 28553, which I fixed before beta1.  In that fix, I changed 
nsCSSFrameConstructor::FindPrimaryFrameFor() to walk the parent frame's sibling 
list looking for siblings that are mapped to the same content.  That tells us 
that the sibling frames were created by the "special" block-in-inline frame 
code, and we need to search them as well because logically they are an extension 
of the primary frame.

What that code needs to do in addition is do the same thing for all ancestors up 
the parent tree, whenever a primary frame cannot be found.

The interesting part of the frame tree for the test case looks like this:
Area(html)(-1)@011DA6FC
  line 011DA7CC
    Text(1)@011DA748
      "\n"
  line 011DA7F4
    Block(body)(2)@011DA784
      line 011DAC00
        Text(0)@011DA81C
          "\n\n"
        Inline(font)(1)@011DA858 
          Text(0)@011DA890
            "\n"
          Inline(span)(1)@011DA8CC
            Text(0)@011DA904[0,1,T]
              "\n"
      line 011DAC28:
        Block(font)(1)@011DAB58
          line 011DABA0
            Block(span)(1)@011DAA74
              line 011DAABC
                Block(p)(1)@011DA940
       line 011DAC50
        Inline(font)(1)@011DABC8
          Inline(span)(1)@011DAAE4
            Text(2)@011DA988[0,1,T]
              "\n"
            Inline(a)(3)@011DA9C4
              Text(0)@011DA9FC
                "Mouseover here to see link text multiplying"
            Text(4)@011DAA38
              "\n"
          Text(2)@011DAB1C
            "\n\n"

The current implementation of FindPrimaryFrameFor() won't find the frame for <A> 
because it's buried in a "special" frame several levels down.

Comment 12

[Nisheeth Ranjan]

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

Comment 13

[Nisheeth Ranjan]

This bug is causing a lot of grief.  Fixing this is gonna be the reason of my 
existence for the forseeable future.

Comment 14

[troy]

Wow, that's determination. :-)

Comment 15

[Richard Zach]

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

Comment 16

[Nisheeth Ranjan]

I have a potential fix for this bug.  The patch to the frame constructor is 
attached.  Troy, buster, can you take a look?  Thanks.

Comment 17

[Nisheeth Ranjan]

Attachment: Proposed patch

Comment 18

[Nisheeth Ranjan]

I'm about to attach a modified patch, based on Troy's comments.  Steve, please 
review it.  Thanks.

Comment 19

[Nisheeth Ranjan]

Attachment: Modified patch, based on Troy's comments

Comment 20

[buster]

looks great, r=buster

Comment 21

[Nisheeth Ranjan]

Steve has reviewed this patch and given it his ok.  The fix is checked in.

Comment 22

[Chris Petersen]

Fixed in the April 21 build.