Closed
Bug 19062
Opened 26 years ago
Closed 26 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•26 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M12
|
|
Assignee | |
Comment 3•26 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•26 years ago
|
||
|
|
Assignee | |
Comment 5•26 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•26 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•26 years ago
|
||
|
|
Assignee | |
Comment 8•26 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•26 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
|
|
Assignee | |
Updated•26 years ago
|
Target Milestone: M13 → M12
|
|
Assignee | |
Comment 10•26 years ago
|
||
Just checked in the fix.
|
||
Updated•26 years ago
|
Status: RESOLVED → VERIFIED
|
|
||
Comment 11•26 years ago
|
||
Marking verified per last commenst.
You need to log in
before you can comment on or make changes to this bug.
Description
•