78554 - crash when changing two or more prefs under appearance->colors

Status: VERIFIED WORKSFORME

(SeaMonkey :: Preferences, defect, P1)

Description

[Dave]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-21mdk i686; en-US; rv:0.8.1+)
Gecko/20010430
BuildID:    2001043009

When the "use system colors" check box is checked or unchecked, along with
changing one of the color prefs (i.e. background, link color, text, etc), the
browser crashes upon hitting "OK"

I first noticed this when I installed a new build with a new profile and told
prefs to not use system colors and use white for the background color. It
appears to crash with any other combination though.

Reproducible: Always
Steps to Reproduce:
1. Open prefs->appearance->colors
2. Change the value of the "use system colors" check box
3. Change one of the colors
4. Hit the OK button

Actual Results:  The browser crashes after the OK button is pressed.

Expected Results:  Browser shouldn't crash

I found quite a few bugs involving color prefs (they don't work, they're not
migrated, etc) but none involving a crash, so I'm filing this one.

Comment 1

[Dave]

OK, I did a little more research and the crash is caused by changing more than
one pref at a time within prefs->appearance->colors.
i.e. the new steps to reproduce are:

1. Open prefs->appearance->colors
2. Change the value of _at least two_ attributes from among "use system colors",
"underline links", or any of the actual colors (background, text, links).
3. Hit the OK button

Only changing one of the prefs won't cause a crash.

Comment 2

[Daniel Veditz [:dveditz]]

Not a backend problem.

Comment 3

[sairuh (rarely reading bugmail)]

hi Dave. i tried this using 2001.05.02.08 bits [comm, but still linux], and
couldn't get a crash when i changed two Colors settings [turned off system
colors and underlining of links]. for kicks, also tried out on Mac and winNT,
but couldn't repro.

marking as wfm --however, if you could do this with more recent bits, or find
another related testcase, do reopen!

Comment 4

[Dave]

Still crashing with 2001050209/Linux. Even with creating a new profile through
-ProfileManager.

Comment 5

[Brian Nesse (gone)]

Yes, there is definitly a problem here. I can reproduce this using the
2001042605 bits (pre prefs refactoring landing). As Dan noted, this is not a
backend preferences bug. The crash occurs while the document is reflowing... I
believe nsPresContext was near the top of the stack crawl.

You can also cause this crash by changing the Font preferences... I believe
there is already a bug for that, but I forget the number.

Comment 6

[Dave]

Finally got talkback to install and submitted TB299562856 on this (has my email
address also).

Comment 7

[Kathleen :Brade]

bug #68208?

Comment 8

[Brian Nesse (gone)]

That could be it, the summary doesn't look familiar, but I don't see another bug
that does. I'd have to look at the stack crawl to be certain though because
according to the bug, it should be fixed in the version I repro'd it in.

Comment 9

[Brian Nesse (gone)]

The stack crawl I'm getting (on the font change) is the same as the one in Bug
77779. I believe it was the same stack for the color change.

  0EF57D40    PPC  3DBC9654  PresShell::ProcessReflowCommands(int)+00230
  0EF57C80    PPC  3DBC634C  PresShell::HandlePostedReflowCallbacks()+00060
  0EF57C30    PPC  3DD1A968 
nsXULTreeOuterGroupFrame::ReflowFinished(nsIPresShell*, int*)+000E8
  0EF57B50    PPC  3DD0FEBC  nsTreeLayout::LazyRowCreator(nsBoxLayoutState&,
nsXULTreeGroupFrame*)+000BC
  0EF57AA0    PPC  3DD13348  nsXULTreeGroupFrame::GetFirstTreeBox(int*)+00500
  0EF57860    PPC  3DC98920 
nsCSSFrameConstructor::CreateTreeWidgetContent(nsIPresContext*, nsIFrame*,
nsIFrame*, nsIContent*, nsIFrame**, int, int, nsILayoutHistoryState*)+00258
  0EF57690    PPC  3E1726AC  nsBindingManager::ProcessAttachedQueue()+000F8
  0EF575B0    PPC  3E14EE98  nsXBLBinding::ExecuteAttachedHandler()+00068
  0EF57550    PPC  3E83AE48  nsCOMPtr_base::assign_from_helper(const
nsCOMPtr_helper&, const nsID&)+00028

Comment 10

[sairuh (rarely reading bugmail)]

here's the talkback info:

Incident ID 29956285
Trigger Time 2001-05-03 09:08:28
User Comments again the prefs->colors bug
Build ID 2001050208
Platform ID LinuxIntel
Stack Trace
0x08b3d2dd
xptiInterfaceInfoManager::GetInterfaceInfoManagerNoAddRef()
nsXBLMouseHandler::nsXBLMouseHandler()
NS_NewTextEncoder()
QBCurve::SubDivide()
nsObeliskLayout::ComputeChildSizes()
nsPopupSetBoxObject::DestroyPopup()
nsBox::Redraw()
PresShell::AddDummyLayoutRequest()
nsSimplePageSequenceFrame::StartPrint()
SendStatusNotification()
nsEventQueueServiceImpl::PopThreadEventQueue()
nsThread::nsThread()
libwidget_gtk.so + 0xd299 (0x4053d299)
nsSupportsInterfacePointerImpl::~nsSupportsInterfacePointerImpl()
libwidget_gtk.so + 0xd2d7 (0x4053d2d7)
handle_gdk_event()
libgdk-1.2.so.0 + 0x1700a (0x406cd00a) 

Comment 11

[Paul Chen]

nav triage team:

Looks like an xptoolkit issue. Reassigning to trudelle

Comment 12

[Peter Trudelle]

->arik, p1/0.9.1

Comment 13

[Peter Trudelle]

I can't reproduce this using today's moz build on Linux 2.2.12. Is anyone still
seeing this? ->0.9.2/qawanted until we have a reproducible case.

Comment 14

[Dave]

WFM on 2001050910/Linux... guess someone fixed it.
Feel free to resolve this if noone else can repro.

Comment 15

[sairuh (rarely reading bugmail)]

resolving wfm --do reopen if this crops up again.

Comment 16

[Dave]

color prefs probably need some performance tuning still, but no crash on
2001051008 so verifying.