Closed Bug 45568 Opened 24 years ago Closed 24 years ago

bugzilla "show_bug.cgi" form repeats data

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: waterson, Assigned: waterson)

References

Details

(Keywords: regression, smoketest)

Attachments

(4 files)

minimized test case
279 bytes, text/html
Details
minimized even more
203 bytes, text/html
Details
fix
1.12 KB, patch
Details | Diff | Splinter Review
Still occurs - 082108, win32 (despite what title bar build id is)
51.01 KB, image/gif
Details 
Visit an existing bug. Any bug. You'll see the bugzilla form data repeated, at
least once, maybe more times. You'll crash when you leave the page.
Keywords: dogfood, nsbeta2, regression
Attached file minimized test case — 

    
    

    
  

      
      
      
      

        Attached file
          
        minimized even more
        — 
      

    


  

    
  
Assignee: asa → waterson
Component: Browser-General → Layout
Summary: bugzilla "show_bug.cgi" form repeats data → {ib?} bugzilla "show_bug.cgi" form repeats data

    
    

    
  
This looks like it could be a parser bug compounded with an {ib} bug. The first 
test case produces what appears to be an incorrect content model due to content 
rotation by the parser. The second test case appears to produce the classic 
{ib} problem: the content model is correct but the frame model is horked. 
cc'ing nisheeth and harishd.

I'll start by debugging the {ib} problem in the second test case; harishd, 
could you take a look at the content model produced by the first test case?

    
    

    
  
Ok, I did some more experimenting. This is definitely *not* an {ib} bug, 
because we're never hitting the inline-block construction code. Turns out 
that a <form> is "display: block", so I was just confused.

Here's what I've found out. With this content:

 <FORM><input type="radio"></input><input type="radio"></input><p></p></FORM>

(note the closed <p></p> tag pair), I generate the following frame tree:

 Block(body)(1)@00D53C90 {120,120,8940,270} [state=00000004]<
   line 00D53EF4: count=1 <
     Block(form)(0)@00D53D00 {0,0,8940,270} [state=00000004] <
       line 00D53EA4: count=2 <
         Frame(input)(0)@00D53D64 {45,30,180,180} [state=00000024]
         Frame(input)(1)@00D53DE0 {345,30,180,180} [state=00000024]
       >
       line 00D53ECC: count=1 <
         Block(p)(2)@00D53E5C {0,270,8940,0} [state=00000004] <
         >
       >
     >
   >
 >

With this content:

(note the unclosed <p> tag), I generate the following frame tree:


 Block(body)(1)@00D53C90 {120,120,8940,510} [state=00000014] <
   line 00D53EF4: count=1 <
     Block(form)(0)@00D53D00 next=00D53D64 {0,0,8940,0} [state=00000004] <
     >
   >
   line 00D53F90: count=3 {0,240,900,270} <
     Frame(input)(1)@00D53D64 {45,270,180,180} [state=00000024]
     Frame(input)(1)@00D53DE0 {345,270,180,180} [state=00000024]
     Frame(input)(2)@00D53FB8 {645,270,180,180} [state=00000024]
   >
   line 00D53ECC: count=1 <
     Block(p)(3)@00D53E5C {0,510,8940,0} [state=00000004] <
     >
   >
 >

Note how the input frames have been promoted up outside the <form>! I've been 
setting breakpoints in nsCSSFrameConstructor::ContentAppended() and 
ContentRemoved(), and they're being called several times from the content 
sink's rotation code.

I'll next verify that they are sending correct information to layout. My 
suspicion is that the <p>-closing code is interacting poorly with the 
form-element promotion code, and is not sending layout enough information to 
properly destroy and reconstruct frames.

adding vidur & jst to cc list.
Summary: {ib?} bugzilla "show_bug.cgi" form repeats data → bugzilla "show_bug.cgi" form repeats data

    
    

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

    
    

    
  
adding the smoketest keyword to ensure that we don't open the tree without 
getting this fixed by monday. 
Keywords: smoketest

    
    

    
  
Ok, this was caused by dbaron's recent checkin to nsHTMLInputElement.cpp. What 
happens is something like this.

- The HTML content sink is in the midst of DemoteContainer(), which is removing 
elements out of the <form> and promoting them to the <body>. In the process of 
doing so, it will call nsIContent::SetDocument().

- When it calls this on an nsHTMLInputElement, the SetDocument() implementation 
makes a call to GetPrimaryFrame(). (It does this to eventually get the 
nsIEditor object, which is entraining a pile of anonymous content. This is the 
new code that dbaron added.)

- GetPrimaryFrame() by default will call 
nsHTMLDocument::FlushPendingNotifications() unless you call 
it with aFlushNotifcations set to PR_FALSE.

- FlushPendingNotifications() re-enters the content sink at this inopportune 
time (while it is doing promotion) and generally sets all hell loose.

Calling GetPrimaryFrame() with aFlushNotifcations == PR_FALSE fixes this. There 
is no reason to flush notifications at this point.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        fix
        — 
          — Splinter Review
      

    


  

    
    

    
  
fix checked in, r=mozbot
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED

    
    

    
  
Thanks for fixing this, Chris.  I didn't think GetPrimaryFrame would do anything
other than get the primary frame.  But the main problem was that I didn't test
this change well enough.

    
    

    
  
Sure this fix is 100%?

There's one plagued little page out there that now has an even harder time than
before:
http://www.locigames.com

Now also renders twice :)

    
    

    
  
R.K.Aa, i think the lokigames problem is the result of strict-dtd, but I'm not
sure.  I mentioned it on the dtd collection bug.

    
    

    
  
i visit lokigames regularly these days for news about SimCity. When this bug got
active was the first time i saw it render twice..

    
    

    
  
bug 45614 is another new one, image at yahoo.com loads twice.

    
    

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

    
    

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

    
    

    
  
Sorry - bug 45644 is NOT a dup.

    
    

    
  
I'm still seeing this randomly on some bug reports, 081909. If I see it again
(since it doesn't happen every time), I'll attach a screen shot. Reopen, anyone?

    
    

    
  
setting default qa
QA Contact: doronr → petersen

    
    

    
  
Not able to reproduce problem on the Sept 5th build.Tested on Win 98 and Mac OS 
9. Marking verified fixed.

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: