166750 - Crash on select box with style="position: fixed" inside block box with style="overflow: auto" [@ nsBlockBandData::Init]

Status: VERIFIED FIXED

(Core :: Layout, defect, P1)

Description

[Ed Catmur]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1b) Gecko/20020904
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1b) Gecko/20020904

This code:
	<form style="overflow: auto;">
		<select style="position: fixed;">
			<option>First</option>
			<option>Second</option>
			<option>Third</option>
		</select>
	</form>
will crash Mozilla.

Reproducible: Always

Steps to Reproduce:
1.Save where you are
2.Visit page
Actual Results:  
Mozilla crashes immediately upon attempting to display page.


We may replace the form element with any block element and get the same crash. I
have not found any other controls that give a crash.

I will attach complete Talkback results.

Comment 1

[Ed Catmur]

Attachment: TalkBack results

Comment 2

[Ed Catmur]

Occasionally (~20% of time) Mozilla will stop responding instead of crashing. In
this case, it is possible to close the window by the title bar but the process
remains in memory.

Comment 3

[Adam Hauner]

Same with 2002090308/trunk/W2 -> TB10399465K

Comment 4

[Adam Hauner]

Same with NN700/W2K -> TB10399704Q

Comment 5

[Adam Hauner]

Attachment: testcase

Comment 6

[Chris Petersen]

Able to reproduce the crash when opening the attached test case. Tested under
the 2002-09-09-05 OS X build.

Comment 7

[Boris Zbarsky [:bzbarsky]]

To something like a real owner.

nsBlockBandData::Init
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockBandData.cpp, line 72]
nsBlockReflowState::nsBlockReflowState
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockReflowState.cpp, line 153]
nsBlockFrame::Reflow
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 822]
nsContainerFrame::ReflowChild
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 813]
nsScrollFrame::Reflow
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsScrollFrame.cpp, line 810]
nsListControlFrame::Reflow
[c:/builds/seamonkey/mozilla/layout/html/forms/src/nsListControlFrame.cpp, line 973]
nsContainerFrame::ReflowChild
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 813]
nsComboboxControlFrame::ReflowComboChildFrame
[c:/builds/seamonkey/mozilla/layout/html/forms/src/nsComboboxControlFrame.cpp,
line 690]
nsComboboxControlFrame::Reflow
[c:/builds/seamonkey/mozilla/layout/html/forms/src/nsComboboxControlFrame.cpp,
line 1490]
ViewportFrame::ReflowFixedFrame
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsViewportFrame.cpp, line 378]
ViewportFrame::IncrementalReflow
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsViewportFrame.cpp, line 468]
ViewportFrame::Reflow
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsViewportFrame.cpp, line 536]
IncrementalReflow::Dispatch
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 894]
PresShell::ProcessReflowCommands
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 6373]
ReflowEvent::HandleEvent
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 6218]
PL_HandleEvent [c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c, line 644]
PL_ProcessPendingEvents [c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c,
line 577]
_md_EventReceiverProc [c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c, line
1309]
nsAppShellService::Run
[c:/builds/seamonkey/mozilla/xpfe/appshell/src/nsAppShellService.cpp, line 472]
main1 [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1523]
main [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1870]
WinMain [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1888]
WinMainCRTStartup()
KERNEL32.DLL + 0x17d08 (0x77e97d08) 

Comment 8

[Rick Ju]

Attachment: proposed patch

the problem comes from : 
the nsSelectsAreaFrame which is the only child of nsListControlFrame has a 
mState which is not NS_SPACE_MGR checked. but it should be.

So When it's( nsSelectAreaFrame i mean) parent dont have a SM (
mSpaceManager==nsnull ), the nsSelectAreaFrame::Reflow ( it's
nsBlockFrame::Reflow ) won't new a SM for itself ( refer to
nsBlockFrame.cpp:741 ).

Why mState&NS_SPACE_MGR==false comes from
nsCSSFrameContructor::ConstructSelectFrame ( in 4243 line ).


with the patch, the crash disappeared. but the fixed select is still not
dislayed. 
the reason, i believe, has nothing to do with this bug since it don't work also
for a fixed img in a almost same html.

Comment 9

[John Keiser (jkeiser)]

CC'ing people who know the ins and outs of space manager better than I do.  I
think the patch is right; we *do* need a space manager if we're fixed positioned.

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 100226 [details] [diff] [review]
proposed patch

r=dbaron on the patch -- fixed and absolutely positioned elements should almost
always act the same for things like this.

That said, the fact that we need to do this at all suggests a design problem. 
Perhaps, in the longer term, we should move some of the space-manager creation
logic into the reflow state (i.e., allow it to create a space manager in some
cases if one doesn't already exist, but when it knows a new block formatting
context has been created).  However, I also wonder why we need a space manager
at all for the inside of a select.

Comment 11

[kinmoz]

Comment on attachment 100226 [details] [diff] [review]
proposed patch

sr=[e-mail]

Comment 12

[John Keiser (jkeiser)]

Fix checked in.

Comment 13

[Greg K.]

Verified with Win FF 1.5.

Comment 14

[Jesse Ruderman]

Crashtest added as part of http://hg.mozilla.org/mozilla-central/rev/afc662d52ab1