121860 - Crash when trying to edit preferences appearance themes [@ nsBlockBandData::Init][@ nsBandTrapezoid::nsBandTrapezoid ][@ nsBlockReflowContext::PlaceBlock][@ nsBlockBandData::ComputeAvailSpaceRect]

Status: VERIFIED FIXED

(SeaMonkey :: Preferences, defect, P1)

Description

[[e-mail]]

using 2002012421/linux: crash when doing edit -> preferences -> Appearance/Themes.
Just clicking on the Appearance/themes entry in the edit preferences dialog
crashes mozilla. Talkback IDs TB2110413Y, TB2110341G

Comment 1

[H. Wade Minter]

I'm seeing this one, too.

Comment 2

[Matthias Versen [:Matti]]

confirming based on the dupe

Comment 3

[R.K.Aa.]

Confirming. Seems to happen in layout:

(gdb) bt
#0  0x41673a06 in nsBlockBandData::Init () from libgklayout.so
#1  0x4167ca6c in nsBlockReflowState::nsBlockReflowState ()
#2  0x41674e3d in nsBlockFrame::Reflow ()
#3  0x41750ccd in nsBoxToBlockAdaptor::Reflow ()
#4  0x4174fffb in nsBoxToBlockAdaptor::RefreshSizeCache ()
#5  0x41750552 in nsBoxToBlockAdaptor::GetAscent ()
#6  0x41755409 in nsSprocketLayout::GetAscent ()
#7  0x4175271a in nsContainerBox::GetAscent ()
#8  0x4175e713 in nsBoxFrame::GetAscent ()
#9  0x41755409 in nsSprocketLayout::GetAscent ()
#10 0x4175271a in nsContainerBox::GetAscent ()
#11 0x4175e713 in nsBoxFrame::GetAscent ()
#12 0x4175362c in nsSprocketLayout::Layout ()
#13 0x41752786 in nsContainerBox::DoLayout ()
#14 0x4175e96f in nsBoxFrame::DoLayout ()
#15 0x4174dba8 in nsBox::Layout ()
#16 0x4175656a in nsStackLayout::Layout ()
#17 0x41752786 in nsContainerBox::DoLayout ()
#18 0x4175e96f in nsBoxFrame::DoLayout ()
#19 0x4174dba8 in nsBox::Layout ()
#20 0x4175e4c8 in nsBoxFrame::Reflow ()
#21 0x4174b9d8 in nsRootBoxFrame::Reflow ()
#22 0x41681371 in nsContainerFrame::ReflowChild ()
#23 0x416ce1dd in ViewportFrame::Reflow ()
#24 0x416b340c in PresShell::InitialReflow ()
#25 0x40f2bb2e in nsXULDocument::StartLayout ()
#26 0x40f2fe38 in nsXULDocument::ResumeWalk ()
#27 0x40f307ab in nsXULDocument::OnStreamComplete ()
#28 0x40800a25 in nsStreamLoader::OnStopRequest ()
#29 0x4083a871 in nsJARChannel::OnStopRequest ()
#30 0x40846bf1 in nsOnStopRequestEvent::HandleEvent ()
#31 0x407f2f9f in nsARequestObserverEvent::HandlePLEvent ()
#32 0x40166a2b in PL_HandleEvent ()
#33 0x40166925 in PL_ProcessPendingEvents ()
#34 0x4016796f in nsEventQueueImpl::ProcessPendingEvents ()
#35 0x407064e6 in event_processor_callback ()
#36 0x40706248 in our_gdk_io_invoke ()
#37 0x4038da7a in g_io_unix_dispatch (source_data=0x8232fd8, 
    current_time=0xbffff440, user_data=0x8232fb0) at giounix.c:137
#38 0x4038f055 in g_main_dispatch (dispatch_time=0xbffff440) at gmain.c:656
#39 0x4038f659 in g_main_iterate (block=1, dispatch=1) at gmain.c:877
#40 0x4038f7e8 in g_main_run (loop=0x8233050) at gmain.c:935
#41 0x402a365b in gtk_main () at gtkmain.c:524
#42 0x407069c5 in nsAppShell::Run ()
   from /home/dark2/DISK/mozilla/dist/bin/components/libwidget_gtk.so
#43 0x406e70d6 in nsAppShellService::Run ()
   from /home/dark2/DISK/mozilla/dist/bin/components/libnsappshell.so
#44 0x08051b5b in main1 ()
#45 0x08052465 in main ()
#46 0x404d7627 in __libc_start_main (main=0x805232c <main>, argc=1, 
    ubp_av=0xbffff844, init=0x804ca4c <_init>, fini=0x8053a78 <_fini>, 
    rtld_fini=0x4000dcc4 <_dl_fini>, stack_end=0xbffff83c)
    at ../sysdeps/generic/libc-start.c:129
(gdb) 

Comment 4

[R.K.Aa.]

Tested backing out the checkins for bug 99691: The crash went away.
CC waterson

Comment 5

[Blake Ross]

This is because this panel has an embedded <html:a> which is display: block.

Comment 6

[Chris Waterson]

Eww. Don't do that.

Comment 7

[Chris Waterson]

i'll fix it.

Comment 8

[Chris Waterson]

Attachment: fix

So it turns out that we need the belt-and-braces code inside
nsBoxToBlockAdaptor to make sure that any block contained inside the adaptor
has a space manager. (I suppose that we could crawl back up the frame chain to
see if a space manager exists _above_ us, but that'd suck worse, I think.)

Comment 9

[Blake Ross]

Don't do what?  The link has to be display: block else it doesn't show up (a
bug).  If you mean "don't put links in xul," well, I don't think that's the
answer...

Comment 10

[Chris Waterson]

Or maybe we could do this in the frame constructor: at that point we may be able
to detect that we don't have a floater containing block...

Comment 11

[Chris Waterson]

Oops, meant to reassign to self.

Comment 12

[Chris Waterson]

Attachment: better fix

This is probably a better fix. We leave the floater and absolute containing
blocks null when creating a root box frame, and then create them on the fly
when needed in ConstructBlockFrame.

Comment 13

[Chris Waterson]

Okay, I missed an easy case here. What if somebody just puts an HTML block frame
in a XUL window? (Like we do in the appearance preference panel.)

I think the right way to fix this is to alter the obviously broken code in
nsCSSFrameConstructor::ConstructDocElementFrame, leaving the `absolute
containing block' and the `floater containing block' null in the frame
constructor state if the root element isn't a block.

Then, when we actually initialize a block frame in ConstructBlockFrame, we'll
check the ACB and FCB in the frame constructor state, and if null, then we'll
know that _this_ block needs to be the ACB and the FCB.

This should be better than hacking the belt-and-braces stuff into box-to-block
adaptor.

Comment 14

[Chris Waterson]

Er, themes preference panel! ;-)

Comment 15

[sairuh (rarely reading bugmail)]

also crashes on mac os x -> all.

Comment 16

[sairuh (rarely reading bugmail)]

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

Comment 17

[Patrick]

in browswer clicking VIEW - APPLY THEME - THEME PREFERENCES also crashes browser.
Probably calling same buggy routine

mozilla build 2002012503

Comment 18

[Matthias Versen [:Matti]]

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

Comment 19

[Andrew Hagen]

Like comment 17 implied, a workaround for this problem, if you want to move from
classic to modern, is View | Apply Theme | Modern. 

Comment 20

[Andrew Hagen]

I have the following crash data for this bug: TB2151456X, TB2151459G,
TB2151465Y, TB2151469E. 

Comment 21

[Chris Waterson]

This bug has a fix; what it really could use is some code-review! ;-)

Comment 22

[Andrew Hagen]

This is a bug that a lot of new Mozilla/Netscape 6 users will be exposed to. Fix
already exists, only needs review. Nominating for 0.9.8. Adding mozilla0.9.8
keyword.

Comment 23

[Blake Ross]

This does not exist on the 098 branch.

Comment 24

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

Comment on attachment 66558 [details] [diff] [review]
better fix

r=dbaron, although I'm not sure whether we really want the NS_BLOCK_MARGIN_ROOT
bit set (but I think it seems safer with than without)

Comment 25

[Matthias Versen [:Matti]]

Sorry for this...

[e-mail]:
a)We need no talkback data if the bug already contains a stack trace and a Patch.
We need stack traces only to understand the problem if a bug is difficult to
reproduce or to find the correct owner for a crash.
b) You can't nominate this bug for 0.9.8 because we have already branched and
the branch doesn't have the fix from bug 99691. (=doesn't have this bug)
c) This will fixed ASAP because waterson need only r=/sr=

Please read bugs before you add a comment and avoid SPAM

Comment 26

[Matthias Versen [:Matti]]

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

Comment 27

[R.K.Aa.]

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

Comment 28

[Chris Waterson]

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

Comment 29

[David Hyatt]

sr=hyatt

Comment 30

[Jay Patel [:jay]]

I just logged bug 122283 ... the stack signature and trace are different, but I
have a feeling it might be a dupe of this also.

Comment 31

[R.K.Aa.]

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

Comment 32

[Jay Patel [:jay]]

Adding [@ nsBandTrapezoid::nsBandTrapezoid ] to summary, since bug 122283 was
marked a dup.

Comment 33

[Matthias Versen [:Matti]]

[e-mail]: bug  bug 122283 was never duped ....

Comment 34

[Jay Patel [:jay]]

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

Comment 35

[Jay Patel [:jay]]

whoops! i still think it should be anyway...just marked it so.  please correct
me if i'm wrong.

Comment 36

[Chris Waterson]

Fix checked in.

Comment 37

[wzeikat]

what does 'Fix checked in' mean?

Comment 38

[Chris Waterson]

It means that -- knock on wood -- the next nightly build (i.e., tomorrow's bits)
will not exhibit this bug anymore.

Comment 39

[R.K.Aa.]

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

Comment 40

[Adam Hauner]

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

Comment 41

[R.K.Aa.]

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

Comment 42

[Chris Waterson]

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

Comment 43

[R.K.Aa.]

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

Comment 44

[Blake Ross]

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

Comment 45

[wzeikat]

et voila:
it works fine now in Build 2002012906 on win95.

Comment 46

[sairuh (rarely reading bugmail)]

vrfy'd fixed using 2002.01.29.xx comm bits on linux rh7.2, mac 10.1.2 and win2k.

Comment 47

[Jay Patel [:jay]]

Just so we know which stack signatures this crash was being reported under, I'm
going to list all of them here.   All of these crashes mentioned something about
prefs->themes:

1. nsBlockBandData::Init - original crash reported under this stack signature
2. nsBandTrapezoid::nsBandTrapezoid - 16 crashes on Windows with 1/25 builds
3. nsBlockReflowContext::PlaceBlock - last crash reported was with 1/24 builds
4. nsBlockBandData::ComputeAvailSpaceRect - 16 crashes on Linux with 1/28 builds
(probably from testing)

If they are all related, we shouldn't be seeing any of them in Talkback data
starting today.

Comment 48

[R.K.Aa.]

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

Comment 49

[R.K.Aa.]

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