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)
Core
Layout: Form Controls
Tracking
()
VERIFIED
FIXED
M12
People
(Reporter: hoa.nguyen, Assigned: pollmann)
Details
Attachments
(2 files)
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>
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
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M12
Assignee | ||
Comment 3•25 years ago
|
||
I can't even get a file input to display in today's build. It's also crashing for me. Attaching simplified test case...
Assignee | ||
Comment 4•25 years ago
|
||
Assignee | ||
Comment 5•25 years ago
|
||
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
Assignee | ||
Comment 6•25 years ago
|
||
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.
Assignee | ||
Comment 7•25 years ago
|
||
Assignee | ||
Comment 8•25 years ago
|
||
I'm waiting with an reviewed checkin until the current redness clears.
Moving to m13 (just in case the tree stays red). Eric believes he has a fix in hand with a review no less!
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•25 years ago
|
Target Milestone: M13 → M12
Assignee | ||
Comment 10•25 years ago
|
||
Just checked in the fix.
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 11•25 years ago
|
||
Marking verified per last commenst.
You need to log in
before you can comment on or make changes to this bug.
Description
•