Closed Bug 19062 Opened 25 years ago Closed 25 years ago

Positioning <form> with inline style sheet causes segmentation fault

Categories

(Core :: Layout: Form Controls, defect, P3)

Product:
Core
Component:
Layout: Form Controls
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: hoa.nguyen, Assigned: pollmann)

Details

Attachments

(2 files)

Simplified test case
72 bytes, text/html
Details
Real test case.
424 bytes, text/html
Details 
Positioning a form using inline style sheets in the <form> tag causes a
segmentation fault in the constructor for nsBlockReflowState.  The cause of the
segmentation fault is that aReflowState.mSpaceManager and therefore
mSpaceManager is null.  Since there is no error checking on whether or not this
variable is null, the first time that it is used (around nsBlockFrame.cpp:576),
a segmentation fault occurs.  The fix for this problem is to make sure that we
always pass nsBlockReflowState::nsBlockReflowState a valid space manager
(starting at line 1395 of nsBlockFrame.cpp):

  // Should we create a space manager?
  nsCOMPtr<nsISpaceManager> spaceManager;
  nsISpaceManager*          oldSpaceManager = aReflowState.mSpaceManager;
>>if ((NS_BLOCK_SPACE_MGR & mState) || (NULL == oldSpaceManager)){
    nsSpaceManager* rawPtr = new nsSpaceManager(this);
    if (!rawPtr) {
      return NS_ERROR_OUT_OF_MEMORY;
    }

    spaceManager = do_QueryInterface(rawPtr);

    // Set the space manager in the existing reflow state
    nsHTMLReflowState&  reflowState = (nsHTMLReflowState&)aReflowState;
    reflowState.mSpaceManager = spaceManager.get();
  }

  nsBlockReflowState state(aReflowState, &aPresContext, this, aMetrics);


This the actual HTML code that causes the crash:


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<html>
<head>
	<title>Form positioning test page</title>
</head>

<body>

<h1 align="CENTER">Form positioning test page</h1>

<hr>

<form action="" method="get" id="TestForm" style="position: absolute; top:
300;">
	<input name="TextField1" value="Test" size="10" ><br>
	<input type="submit" name="btnSubmit" value="Submit">
</form>


</body>
</html>
Assignee: troy → pollmann
Component: Layout → HTML Form Controls
No, that's not the way to fix this bug.

The real issue is that the form is absolutely positioned and so it should become
a containing block for absolutely positioned child elements.

As far as making sure it has a space manager, that should happen in the frame
construction code. Function ConstructFrameByTag() needs to make sure that the
form frame specifies the NS_BLOCK_SPACE_MGR flag. I wonder if there are other
block flags needed as well?

The bigger issue is how to make the form frame a containing block for absolutely
positioned child elements.

There are three choices here:
1. use an area frame instead of a block frame. That is problematic, because the
form frame has lots of form specific code. Maybe aggregation could be used to
mix in the form specific code?
2. insert an anonymous area frame inside of the form frame and have it be the
containing block for absolutely positioned child elements. That has some
drawbacks as well
3. create a derived form frame class, nsPositionedFormFrame, and use it when the
form is absolutely positioned

Reassigning to pollmann to ponder. The immediate issue is the GPF
Eric, I have another idea that's probably better. It's easier to discuss in
person
Status: NEW → ASSIGNED
Target Milestone: M12
I can't even get a file input to display in today's build.  It's also crashing
for me.  Attaching simplified test case...
Attached file Simplified test case — 

    
    

    
  
Got this on the console when I viewed the testcase in viewer

nsLineLayout: FileControl(input)(1)@0x82dbd40 metrics=-559038737,-559038737!
nsLineLayout: FileControl(input)(1)@0x82dbd40 didn't set whad
-559038737,-559038737,-559038737,-559038737!
Block(form)(1)@0x82db528: line=0x82ddc20 xmost=-559038737

    
    

    
  
Oops, please ignore the last three comments, as they were on their way to 19085
but got lost.  Troy - the quick fix you mentioned for this bug seems to work, so
I'll do a little more testing then check that one in.

    
    

    
  

      
      
      
      

        Attached file
          
        Real test case.
        — 
      

    


  

    
  
Blocks: 20203

    
    

    
  
I'm waiting with an reviewed checkin until the current redness clears.

    
  
Target Milestone: M12 → M13

    
    

    
  
Moving to m13 (just in case the tree stays red). Eric believes he has a fix in
hand with a review no less!

    
  
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED

    
  
Target Milestone: M13 → M12

    
    

    
  
Just checked in the fix.

    
  
Blocks: 21564

    
  
Status: RESOLVED → VERIFIED

    
    

    
  
Marking verified per last commenst.

    
  
No longer blocks: 20203

    
  
No longer blocks: 21564

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: