Closed
Bug 200347
Opened 22 years ago
Closed 22 years ago
browser crashes on fieldset with position:fixed-style - Trunk M140B [@ nsSpaceManager::GetTranslation] [@ nsBlockBandData::Init]
Categories
(Core :: Layout: Form Controls, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: theseer, Unassigned)
References
Details
(Keywords: crash, testcase, topcrash+, Whiteboard: landed1.4?)
Crash Data
Attachments
(3 files, 3 obsolete files)
1.81 KB,
patch
|
Details | Diff | Splinter Review | |
8.45 KB,
patch
|
kinmoz
:
review+
dbaron
:
superreview+
asa
:
approval1.4+
|
Details | Diff | Splinter Review |
455 bytes,
text/html
|
Details |
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401
Even though the given testcase might be an abusive use of CSS and as of that to
be considered invalid html the browser crashes on loading this page.
Reproducible: Always
Steps to Reproduce:
1. load the testcase
Actual Results:
crash
Expected Results:
rendered the page - at least somehow ;)
<html>
<body>
<fieldset style="position:fixed;">
<legend class="bblack14">Crash test</legend>
hello world content
</fieldset>
</body>
</html>
Comment 1•22 years ago
|
||
###!!! ASSERTION: SpaceManager should be set in nsBlockReflowState:
'mSpaceManager', file nsBlockReflowState.cpp, line 90
Break: at file nsBlockReflowState.cpp, line 90
###!!! ASSERTION: null pointer: 'aSpaceManager', file nsBlockBandData.cpp, line
68
Break: at file nsBlockBandData.cpp, line 68
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 4274)]
0x4117cd0d in nsSpaceManager::GetTranslation (this=0x0, aX=@0xbfffe330,
aY=@0xbfffe334) at ../../../base/src/nsSpaceManager.h:194
194 void GetTranslation(nscoord& aX, nscoord& aY) const { aX = mX; aY =
mY; }
(gdb) bt
#0 0x4117cd0d in nsSpaceManager::GetTranslation (this=0x0, aX=@0xbfffe330,
aY=@0xbfffe334) at ../../../base/src/nsSpaceManager.h:194
#1 0x40da2782 in nsBlockBandData::Init (this=0xbfffe320, aSpaceManager=0x0,
aSpace=@0xbfffe2d0) at nsBlockBandData.cpp:71
#2 0x40db1948 in nsBlockReflowState::nsBlockReflowState (this=0xbfffe2b0,
aReflowState=@0xbfffe5d0, aPresContext=0x88ecdd0, aFrame=0x892bac0,
aMetrics=@0xbfffe6c0, aBlockMarginRoot=0) at nsBlockReflowState.cpp:148
#3 0x40da4285 in nsBlockFrame::Reflow (this=0x892bac0,
aPresContext=0x88ecdd0, aMetrics=@0xbfffe6c0, aReflowState=@0xbfffe5d0,
aStatus=@0xbfffea5c) at nsBlockFrame.cpp:810
[...]
Comment 2•22 years ago
|
||
No dupes found, marking NEW.
more vars from GDB (I'm lost after frame 3):
(gdb) frame 1
#1 0x40da2782 in nsBlockBandData::Init (this=0xbfffe320, aSpaceManager=0x0,
aSpace=@0xbfffe2d0) at nsBlockBandData.cpp:71
71 aSpaceManager->GetTranslation(mSpaceManagerX, mSpaceManagerY);
(gdb) p aSpaceManager
$9 = (nsSpaceManager *) 0x0
(gdb) frame 1
#1 0x40da2782 in nsBlockBandData::Init (this=0xbfffe320, aSpaceManager=0x0,
aSpace=@0xbfffe2d0) at nsBlockBandData.cpp:71
71 aSpaceManager->GetTranslation(mSpaceManagerX, mSpaceManagerY);
(gdb) p mSpaceManagerX
$10 = 0
(gdb) p mSpaceManagerY
$11 = 0
(gdb) frame 2
#2 0x40db1948 in nsBlockReflowState::nsBlockReflowState (this=0xbfffe2b0,
aReflowState=@0xbfffe5d0, aPresContext=0x88ecdd0, aFrame=0x892bac0,
aMetrics=@0xbfffe6c0, aBlockMarginRoot=0) at nsBlockReflowState.cpp:148
148 mBand.Init(mSpaceManager, mContentArea);
(gdb) p aReflowState.mSpaceManager
$12 = (nsSpaceManager *) 0x0
(gdb) frame 3
#3 0x40da4285 in nsBlockFrame::Reflow (this=0x892bac0,
aPresContext=0x88ecdd0, aMetrics=@0xbfffe6c0, aReflowState=@0xbfffe5d0,
aStatus=@0xbfffea5c) at nsBlockFrame.cpp:810
810 NS_BLOCK_MARGIN_ROOT & mState);
Assignee: asa → roc+moz
Status: UNCONFIRMED → NEW
Component: Browser-General → Layout: View Rendering
Ever confirmed: true
QA Contact: asa → ian
Comment 3•22 years ago
|
||
So the problem is that the fieldset frame does nothing with the
NS_BLOCK_SPACE_MGR flag that's set on it when it's created. As in, it does not
create a space manager in its reflow method. If it's fixed-positioned, there is
no space manager coming in in the reflow state... so there is no space manager
in the reflow state given to the legend frame. Now the legend frame does _not_
have the space manager state bit set, so it never creates one, flows as a block,
and crashes.
Possible solutions:
1) Set that bit on legend frames
2) Make the fieldset frame respect that bit (depending on what the desired
behavior is, here....)
Component: Layout: View Rendering → Layout: Form Controls
Comment 5•22 years ago
|
||
This fixes the crash; dunno if this gives us the right behavior, though....
Comment 6•22 years ago
|
||
I added a float and some more text to the div to test the effect of the space
manager.
Comment 7•22 years ago
|
||
This fixes the crash too, more at its root, but the space manager created
doesn't seem to work--floats don't float, and I thought that wsa the purpose of
the space manager. I wonder why fieldset does not simply inherit from div.
That's all it is, a div with a funky border.
Comment 8•22 years ago
|
||
Oh yeah, I moved nsAutoSpaceManager from nsBlockFrame.cpp into
nsSpaceManager.h.
Attachment #120983 -
Attachment is obsolete: true
Comment 9•22 years ago
|
||
OK, the floaters float when the fieldset has a fixed width, I bet the fact that
it was not floating in the other testcase is related to a bug on fixed width
unconstrained width fieldsets.
Attachment #120982 -
Attachment is obsolete: true
Updated•22 years ago
|
Attachment #121007 -
Attachment is obsolete: true
Comment 10•22 years ago
|
||
oops, that last testcase was the patch, not the testcase
Updated•22 years ago
|
Attachment #121000 -
Flags: review?(kin)
Comment 11•22 years ago
|
||
Comment on attachment 121000 [details] [diff] [review]
AutoSpaceManager Patch v1.1
So I'm wondering if we really want code in layout/base dependent on headers in
layout/html/base.
If the code for nsAutoSpaceManager is going to rely on nsHTMLReflowState,
should it be moved to nsHTMLContainerFrame instead? Or if you really want it to
live in the space manager code in layout/base, should it be made more generic?
That is, should nsAutoSpaceManager be modified to just manage an
nsSpaceManager** pointer to avoid sucking in nsHTMLReflowState.h since that's
all it really needs?
Comment 12•22 years ago
|
||
Well, nsHTMLReflowState is so basic, required for reflow, that I think "move
nsHTMLReflowState to layout/base" is more the appropriate action. I think
nsAutoSpaceManager is really designed to work with a reflow state (its job is to
switch out space managers when a block requires a new space manager), so it is
appropriate to place it there. I also think it really belongs in
nsSpaceManager, but I'd be willing to move it into nsHTMLReflowState (that's not
such a bad choice either) or its own file in layout/html/base if people so desire.
Comment 14•22 years ago
|
||
No target milestone?
I have seen this bug on two spanish webpages, so in the near future this bug
could be used to hurt mozilla users :-(
Comment 15•22 years ago
|
||
Somebody had the courtesy to mention this on Slashdot today, "in the interest
of fairness", since /. posted a similar crasher for IE a couple of days ago.
Anyway, expect all the L337 Hax0R wannabe kids to start sticking this on pages,
trying to screw with Moz users...
Comment 16•22 years ago
|
||
Is this bug a regression of bug 130251 - they seem pretty similar.
Comment 17•22 years ago
|
||
*** Bug 204849 has been marked as a duplicate of this bug. ***
Comment 18•22 years ago
|
||
Kin, want to reconsider review? HTMLReflowState should probably move to
layout/base, but I think that's out of scope. Refactoring is also possible, or
moving it into its own file, though I prefer the first one.
Comment 19•22 years ago
|
||
Adding Trunk M140B and [@ nsBlockBandData::Init] to summary and topcrash+
keyword. A lot of users have been crashing on a test page posted on SlashDot.
Here is one set of crashes for M140B:
Count Offset Real Signature
[ 8 nsBlockBandData::Init edc92ffd - nsBlockBandData::Init ]
[ 2 nsBlockBandData::Init a6ce067a - nsBlockBandData::Init ]
[ 2 nsBlockBandData::Init 8230fba5 - nsBlockBandData::Init ]
[ 2 nsBlockBandData::Init 74914da7 - nsBlockBandData::Init ]
[ 1 nsBlockBandData::Init f6ede7d0 - nsBlockBandData::Init ]
[ 1 nsBlockBandData::Init f2f28dc2 - nsBlockBandData::Init ]
[ 1 nsBlockBandData::Init 957a816d - nsBlockBandData::Init ]
[ 1 nsBlockBandData::Init 7127f19e - nsBlockBandData::Init ]
[ 1 nsBlockBandData::Init 6bfb8d28 - nsBlockBandData::Init ]
Crash date range: 2003-05-07 to 2003-05-11
Min/Max Seconds since last crash: 15 - 44620
Min/Max Runtime: 18 - 44620
Count Platform List
11 Windows NT 5.0 build 2195
3 Windows NT 5.1 build 2600
2 Windows NT 4.0 build 1381
2 Windows 98 4.10 build 67766446
1 Windows 98 4.90 build 73010104
Count Build Id List
19 2003050714
No of Unique Users 17
Stack trace(Frame)
nsBlockBandData::Init
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockBandData.cpp line 71]
nsBlockReflowState::nsBlockReflowState
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockReflowState.cpp line 151]
nsBlockFrame::Reflow
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp line 821]
nsLegendFrame::Reflow
[c:/builds/seamonkey/mozilla/layout/html/forms/src/nsLegendFrame.cpp line 127]
nsContainerFrame::ReflowChild
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp line 973]
nsFieldSetFrame::Reflow
[c:/builds/seamonkey/mozilla/layout/html/forms/src/nsFieldSetFrame.cpp line 418]
nsAbsoluteContainingBlock::ReflowAbsoluteFrame
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsAbsoluteContainingBlock.cpp
line 508]
nsAbsoluteContainingBlock::IncrementalReflow
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsAbsoluteContainingBlock.cpp
line 341]
ViewportFrame::Reflow
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsViewportFrame.cpp line 314]
IncrementalReflow::Dispatch
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp line 916]
PresShell::ProcessReflowCommands
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp line 6664]
ReflowEvent::HandleEvent
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp line 6509]
PL_HandleEvent [c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c line 660]
PL_ProcessPendingEvents [c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c
line 596]
_md_EventReceiverProc [c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c
line 1396]
nsAppShellService::Run
[c:/builds/seamonkey/mozilla/xpfe/appshell/src/nsAppShellService.cpp line 479]
main1 [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp line 1284]
main [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp line 1650]
WinMain [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp line 1672]
WinMainCRTStartup()
KERNEL32.dll + 0x2847c (0x77ea847c)
(19928566) Comments: <html> <fieldset style="position:fixed;">
<legend>Hybris</legend> </fieldset> </html>
(19915709) Comments: Code posted on slashdot to crash a mozilla browser:
<html> <fieldset style="position:fixed;">
<legend>Crash</legend> </fieldset> </html>
(19915562) Comments: <html> <fieldset style="position:fixed;">
<legend>Crash</leyend> </fieldset> </html>
(19910316) Comments: Visiting a test page that claims to crash Mozilla. It
was right.
(19888830) URL: http://www.geeklife.com/files/crashMoz.html
(19888830) Comments: This is a 5-line HTML page which crashes Mozilla.
This was listed in a Slashdot story:
http://slashdot.org/article.pl?sid=03/05/05/2038222&mode=nested&tid=167&tid=99
This crashed the most recently downloaded Mozilla (1.4 beta).
(19887663) URL: http://www.geeklife.com/files/crashMoz.html
Since we have a patch ready and a easily reproducible testcase, I'm also
nominating this for blocking1.4? Any chance of getting this fix in for Mozilla
1.4 final?
Flags: blocking1.4?
Keywords: topcrash+
Summary: browser crashes on fieldset with position:fixed-style [@ nsSpaceManager::GetTranslation ] → browser crashes on fieldset with position:fixed-style - Trunk M140B [@ nsSpaceManager::GetTranslation] [@ nsBlockBandData::Init]
Comment 20•22 years ago
|
||
*** Bug 205409 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
Flags: blocking1.4? → blocking1.4+
Comment 21•22 years ago
|
||
Comment on attachment 121000 [details] [diff] [review]
AutoSpaceManager Patch v1.1
r=kin@netscape.com
Attachment #121000 -
Flags: review?(kin) → review+
Comment 22•22 years ago
|
||
John, do we need another review on this? Can we get it landed soon?
--Asa
Updated•22 years ago
|
Attachment #121000 -
Flags: superreview?(dbaron)
Attachment #121000 -
Flags: superreview?(dbaron) → superreview+
Updated•22 years ago
|
Attachment #121000 -
Flags: approval1.4?
Comment 23•22 years ago
|
||
Comment on attachment 121000 [details] [diff] [review]
AutoSpaceManager Patch v1.1
a=asa (on behalf of drivers) for checkin to 1.4
Attachment #121000 -
Flags: approval1.4? → approval1.4+
Comment 25•22 years ago
|
||
Fix checked in.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment 26•21 years ago
|
||
*** Bug 207839 has been marked as a duplicate of this bug. ***
Depends on: 323946
Comment 28•16 years ago
|
||
Crashtest added as part of http://hg.mozilla.org/mozilla-central/rev/afc662d52ab1
Flags: in-testsuite+
Updated•13 years ago
|
Crash Signature: [@ nsSpaceManager::GetTranslation]
[@ nsBlockBandData::Init]
You need to log in
before you can comment on or make changes to this bug.
Description
•