283385 - Crash [@ nsBlockBandData::Init] using position:fixed on embed with unknown plugin

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Martijn Wargers (dead)]

See upcoming testcase.

talkback ID: 3894316

nsBlockBandData::Init 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/generic/nsBlockBandData.cpp,
line 70]
nsBlockFrame::Reflow 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/generic/nsBlockFrame.cpp,
line 694]
nsContainerFrame::ReflowChild 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/generic/nsContainerFrame.cpp,
line 957]
nsObjectFrame::HandleChild 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/generic/nsObjectFrame.cpp,
line 1473]
nsObjectFrame::Reflow 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/generic/nsObjectFrame.cpp,
line 1074]
nsAbsoluteContainingBlock::ReflowAbsoluteFrame 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/generic/nsAbsoluteContainingBlock.cpp,
line 689]
nsAbsoluteContainingBlock::Reflow 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/generic/nsAbsoluteContainingBlock.cpp,
line 208]
ViewportFrame::Reflow 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/generic/nsViewportFrame.cpp,
line 300]
IncrementalReflow::Dispatch 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/base/nsPresShell.cpp,
line 908]
PresShell::ProcessReflowCommands 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/base/nsPresShell.cpp,
line 6368]
ReflowEvent::HandleEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/base/nsPresShell.cpp,
line 6194]
PL_HandleEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/xpcom/threads/plevent.c,
line 699]
SHELL32.dll + 0x520c24 (0x778b0c24)

Comment 1

[Martijn Wargers (dead)]

Attachment: Testcase (crashes on load)

Comment 2

[Martijn Wargers (dead)]

I don't crash with:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20050104
Firefox/1.0+ 7:58am
I do crash with:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20050105
Firefox/1.0+ 8:11am
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-01-04+07%3A00%3A00&maxdate=2005-01-05+09%3A00%3A00&cvsroot=%2Fcvsroot

There is a difference between Firefox and Mozilla here. In latest Firefox trunk
builds, I crash directly with the testcase. In latest Mozilla trunk build, I
have to do a reload and after that it usually crashes.

Comment 3

[Bernd]

I would guess thats a followup of the pluginfinder landing from bug 244125

Comment 4

[Boris Zbarsky [:bzbarsky]]

So the problem here is the following frame structure:

Viewport
  Object
    Block

The block doesn't have the space manager bit set, because it's inserted
dynamically and GetFloatContainingBlock will fall back on
mInitialContainingBlock if it doesn't find anything else.  So in
ConstructBlockFrame we don't set the space manager bit here...  Then when we
reflow we have a null space manager, and crash.

The only reason this doesn't bite "normal" fixed-pos blocks is that they create
a NS_NewAbsoluteItemWrapperFrame, which sets the SPACE_MGR and MARGIN_ROOT flags.

Now in all this, I think the behavior of GetFloatContainingBlock is wrong.  As
things stand, mInitialContainingBlock can be a box, or a table, or an svg outer.
 Falling back to it as a containing block for floats is wrong, especially
because it leads to different behavior between a full frame construct from the
top (which only pushes actual block roots as the float containing block) and
dynamic insertions (which use GetFloatContainingBlock).

Comment 5

[Boris Zbarsky [:bzbarsky]]

OK, just fixing that does not help enough... The next problem is that
GetFloatContainingBlock() assumes anything with BLOCK or LIST_ITEM display is a
good float containing block.  That's clearly not true in this case...

The problem then is what we really want to look for here.  Clearly frames of
type block and area are ok.  Probably need legend.  And fieldset.  And so forth...

Perhaps we should have a virtual "IsFloatContainingBlock()" on nsIFrame?  And
only return true from block frames?  That's the only way I see short of
hardcoding a list of all possible frame types that floats could live inside.

Comment 6

[Ben Fowler]

Attachment: Stack

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050227
Firefox/1.0+

The testcase crashes for me.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Ben, we know it crashes, why it crashes, and event what the right fix should
probably be.... see bug comments.

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to comment #5)
> Perhaps we should have a virtual "IsFloatContainingBlock()" on nsIFrame?  And
> only return true from block frames?  That's the only way I see short of
> hardcoding a list of all possible frame types that floats could live inside.

yeah

Comment 9

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch

Untested thus far...  but should also fix the issues in bug 285165.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Attachment: This should do it....

Comment 11

[Boris Zbarsky [:bzbarsky]]

Note, even with that patch the testcase will crash when you _leave_ the page
(that's bug 286004, as far as I can tell).

Comment 12

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 177711 [details] [diff] [review]
This should do it....

Actually, this doesn't help, because the object hack doesn't even use the frame
constructor...

Comment 13

[Boris Zbarsky [:bzbarsky]]

Attachment: Tested and all

The nsObjectFrame change is the only change strictly necessary for this bug, I
guess... but the rest of it really does need to happen too.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Fixed.

Comment 15

[Mats Palmgren (inactive)]

*** Bug 304332 has been marked as a duplicate of this bug. ***