This signature is still showing up in large numbers on the Trunk (22 incidents), M11A (52) and M100 (24). I crashed the 20020708 Trunk build with these steps: 1. Go to prefs 2. Change the minimum font size from "None" to "14pt". I wasn't able to reproduce a second time with those steps, but users are reporting crashes at this signature with a variety of similar, simple pref changes. Here's what I got: Stack Signature nsQueryInterface::operator() 3ec9ba9e Product ID MozillaTrunk Build ID 2002070808 Trigger Time 2002-07-09 09:49:17 Platform Win32 Operating System Windows NT 5.0 build 2195 Module xpcom.dll Trigger Reason Access violation Source File Name c:/builds/seamonkey/mozilla/xpcom/glue/nsCOMPtr.cpp Trigger Line No. 52 Stack Trace nsQueryInterface::operator() [c:/builds/seamonkey/mozilla/xpcom/glue/nsCOMPtr.cpp, line 52] nsCOMPtr_base::assign_from_helper [c:/builds/seamonkey/mozilla/xpcom/glue/nsCOMPtr.cpp, line 81] nsPresContext::PreferenceChanged [c:/builds/seamonkey/mozilla/layout/base/src/nsPresContext.cpp, line 602] nsPresContext::PrefChangedCallback [c:/builds/seamonkey/mozilla/layout/base/src/nsPresContext.cpp, line 103] pref_DoCallback [c:/builds/seamonkey/mozilla/modules/libpref/src/prefapi.cpp, line 1165] pref_HashPref [c:/builds/seamonkey/mozilla/modules/libpref/src/prefapi.cpp, line 1051] PREF_SetIntPref [c:/builds/seamonkey/mozilla/modules/libpref/src/prefapi.cpp, line 540] nsPrefBranch::SetIntPref [c:/builds/seamonkey/mozilla/modules/libpref/src/nsPrefBranch.cpp, line 258] nsPrefService::SetIntPref [c:/builds/seamonkey/mozilla/modules/libpref/src/nsPrefService.h, line 57] nsPref::SetIntPref [c:/builds/seamonkey/mozilla/modules/libpref/src/nsPref.cpp, line 245] XPTC_InvokeByIndex [c:/builds/seamonkey/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp, line 106] XPCWrappedNative::CallMethod [c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 1996] XPC_WN_CallMethod [c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1267] js_Invoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 790] js_Interpret [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 2744] js_Invoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 806] js_InternalInvoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 881] JS_CallFunctionValue [c:/builds/seamonkey/mozilla/js/src/jsapi.c, line 3430] nsJSContext::CallEventHandler [c:/builds/seamonkey/mozilla/dom/src/base/nsJSEnvironment.cpp, line 1045] GlobalWindowImpl::RunTimeout [c:/builds/seamonkey/mozilla/dom/src/base/nsGlobalWindow.cpp, line 4558] GlobalWindowImpl::TimerCallback [c:/builds/seamonkey/mozilla/dom/src/base/nsGlobalWindow.cpp, line 4905] nsTimerImpl::Fire [c:/builds/seamonkey/mozilla/xpcom/threads/nsTimerImpl.cpp, line 340] PL_HandleEvent [c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c, line 597] PL_ProcessPendingEvents [c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c, line 530] _md_EventReceiverProc [c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c, line 1078] nsAppShellService::Run [c:/builds/seamonkey/mozilla/xpfe/appshell/src/nsAppShellService.cpp, line 452] main1 [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1472] main [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1808] WinMain [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1826] WinMainCRTStartup() KERNEL32.DLL + 0xd326 (0x77e8d326)

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

layout should take the first crack.

reassigning to Kevin. I don't think Marc tinkers with layout anymore.

I can't seem to reproduce this on a July 18th trunk build (2002-07-18-13) or July 22 branch build (2002-07-22-08) under Windows ME. Any specific site this still crashes on ?

i don't think it's url specific. looking at m11b using climate, here's a desciptive user comment: Two windows open. The frameset for the online book "thinking in java" (mindview.net) opened from a local file (2 frames one file is ~300KB) another window with some web page. Mozilla had been running since yesterday. I changed the font sizes for the second or third time this session and clicked "OK" then it crashed. this person was using build id 2002072204 on a win2000.

I just had a nearly identical crash in 20020805 macosx-latest-trunk. With various tabs open, I went to Preferences --> Appearance --> Fonts and changed my monospace font from Courier to Courier New. I pressed OK, a few seconds later Mozilla crashed. This bug should change from PC/W2K to All/All.

->alex

20020816 osx-latest-trunk build, same crash upon exiting prefs.

ok, i see that there is a dangling pointer to a nsWebShell that is keept (in form of a raw pointer - not really weak reference) by the nsPresContext object involved in the crash trough its member nsISupports* mContainer. since i cannot guarantee that the container can be made an nsIWeakReference (not even the nsWebShell supports nsIWeakReference at this moment) i will have to find a way to reproduce. i suspect that there is an issue related to character encoding, however not 100% sure.

*** This bug has been marked as a duplicate of 160656 ***

timeless, are you sure that this is a dup? in the case here we don't access a null pointer but a pointer to a defunct nsWebShell.

reopening.

aha@pinknet.cz, i saw your reports on talkback. can you reproduce this frequently? could you provide steps please? please try to figure out under what circumstances the crash occurs. thanks!

some hints from reporters: - changed preferences from accepting all images to only images from server please, cc me to bug with this problem http://www.visibone.com/html/cer_1700.gif - trying Bug-jp 2548 http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=2548 when opening http://ajisai.sakura.ne.jp/~morning/, change Minimum font size none => 6 => 9 => none. - Trying to turn off colors with the preferences toolbar http://slashdot.org/ builds: 2002053015 Gecko1.0 2002061104 MozillaTrunk 2002061815 Gecko1.0 2002072104 MozillaTrunk 2002080208 MozillaTrunk 2002081716 MozillaTrunk 2002081808 MozillaTrunk 2002081904 MozillaTrunk 2002082008 MozillaTrunk 2002082304 MozillaTrunk 2002082310 Gecko1.0 2002082400 MozillaTrunk 2002082611 MozillaTrunk (a lot of reports) 2002082814 MozillaTrunk 2002090404 MozillaTrunk 2002090704 MozillaTrunk 2002091014 MozillaTrunk 2002091108 MozillaTrunk 2002091608 MozillaTrunk

I have an idea, that crash occurs when user is changing some visual preference while page content is loading (in actual window or in one or several tabs). I'm crashed twice when I had changed image blocking (second was attempt to reproduce - TB11117873X, but Mozilla crashed only in 1st attempt).

Adam, can you find steps to reproduce this in a reliable way? that would help a lot.

I'm sorry, but I don't.

Recently, cnn.com chaged the layout of their site and it has been screwing up on my screen. Going in and changing the font prefs has sometimes helped, but just now I crashed on the site. Alex, you could try there, you might get lucky. :)

I believe that this bug, and bug 160656, are both dupes of bug 150893. (All three have essentially the same stack trace attached.)

see comment 10 and comment 11

I realize that. But if I understand correctly, when you made comment 11 it was still hoped that the pointer patch in bug 160656 would fix that bug, and it hasn't. (The bug was reopened.) Nor has it fixed bug 150893, which seems to have just the same stack trace.

oh, sorry, i thought they were able to reproduce and prove that there was a null pointer involved. so it was just a wallpaper patch? well, in that case they might be dupes. still i wouldn't close this one since it has all this tracking keywords and []'s, but rather go and mark the other ones as a dup of this one. still there is no hurry. three bugs open means more people working on them so the chances for a fix are bigger :-) anyway, thanks or the hint.

yep, i see there something very suscceptible of causing this kind of crash: *** Forcing reframe! *** This message is dumped in PresShell::SetPreferenceStyleRules and is telling us about teh iminent call to ReconstructFrames(). investigating

hmm, the crash seems to happen before that

kin, there is also bug 150893 and bug 160656 but looks like there is not much activity on those (they are prtty much dups of this one). So from what I can tell so far is that there is a PresContext that tries to access a defunct WebShell. The prefrences service notifies the PresContext with a callback that prefs have being changed, and from the code, i think that registering/ unregistering the PresContext with the prefs service is done correctly. There is that thing Don told us about some changes dbaron made that keep the PresContext around for a while even though all other members have beeing destroyed for whatever reasons. The PresContext keeps a weak reference to the WebShell in mContainer (is actually just a simple nsISupports*) and cannot know that the WebShell is invalid. Now we could eventually try to use nsIWeakReference instead of nsISupports, but i don't know what kind of objects can these containers be. I'm still investigating this issue, but don't mind if you jump in.

you've, missed 1.2a, this is still a topcrash, helpwanted...

Alex, I have maybe testcase (I'm crashing -> TB11989460Y, but I'm not sure, if it is this bug). Repro: 1. open Edit | Preferences | Priv & Secur | Images 2. choose Accept All Images and click Okay 3. go to testcase for bug 169161 http://bugzilla.mozilla.org/attachment.cgi?id=99504&action=view 4. open Edit | Preferences | Priv & Secur | Images 5. choose Accept Images that come ... and click Okay ... I'm crashing here (but maybe it's bug 150893 or something else).

i tried that and it does not crash for me. :-(

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

moving the cc's from 160656 to this one.

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

cc'ing all from bug 150893

so, this is a hot issue now :-). any clues about how to reproduce or how to fix are more than welcome. if you're able to reproduce, please spend some time and see if you can figure out what are the settings on your machine that create the favorable circumstances for the crash. every detail could be important (like what windows are open at the time, what is the layout/configuration of the sidebar, mailnews client window, where was the focus, are there any iframes in the open documents, are there any plugins, and so on). try playing around and see if you can get rid of the crash and why were you able to do that. this is a frequent crash, but it seems to be bound to particular users and their machines. maybe some particular browsing habits.

I am only able to reproduce by having the bugzilla sidebar open and then editing/saving any preferences under "Apearance".

Brad, i suspected something like that. What is open in the sidebar and what page is open in the browser? Also, do you have any other windows open? Can you reproduce it on a regular basis?

The steps to reproduce this bug remind me of bug 136513. The stack is even quite similar, except for a chunk that's missing at the top, which makes it quite different, unless there's bogus stack reporting going on somehow.

I can consistantly reproduce on multiple boxes Sidebar open: a bugzilla sidebar freshly installed from http://bugzilla.mozilla.org Web page open: this bug makes it crash, as do most other pages. No other browsers open, no other tabs. If you can't track it down soon I can figure out how to checkout/build and maybe give you some specific info, but I'm not very experienced with c++

There is a proposed patch for this exact crash in bug 150769. It just uses nsIWeakReference as Alexandru seems to have suggested in this bug, since the container is always a docshell. The alternative is to do a !mPresShell check right at the beginning of the prefs callback and bail out if we have no presshell at that point.

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

people should test this with tomorrow's trunk builds.

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

Are people still seeing this?

Is it still showing up in TB reports?

This comment has been removed.

temporarily making this confidential for privacy reasons.

Mozilla 1.3a Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021112 On Win2k I can no longer reproduce the crash.

So does comment 45 indicate that the latest TB report containing this stack was generated by 2002110808? That would be after the check-in of bug 150769. Is here any way to tell if that was the 2002-11-08-08-trunk build? Maybe we should give it another week or so to see if any more such crashes come in.

Here is a crash from yesterdays trunk build: Stack Signature nsQueryInterface::operator() 92e427a7 Product ID MozillaTrunk Build ID 2002111108 Trigger Time 2002-11-12 12:51:10 Platform Win32 Operating System Windows NT 5.1 build 2600 Module xpcom.dll URL visited User Comments Trigger Reason Access violation Source File Name c:/builds/seamonkey/mozilla/xpcom/glue/nsCOMPtr.cpp Trigger Line No. 52 Stack Trace nsQueryInterface::operator() [c:/builds/seamonkey/mozilla/xpcom/glue/nsCOMPtr.cpp, line 52] nsCOMPtr_base::assign_from_helper [c:/builds/seamonkey/mozilla/xpcom/glue/nsCOMPtr.cpp, line 81] XPCWrappedNative::GetNewOrUsed [c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 225] XPCConvert::NativeInterface2JSObject [c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcconvert.cpp, line 1061] XPCConvert::NativeData2JS [c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcconvert.cpp, line 462] nsXPCWrappedJSClass::CallMethod [c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 1096] nsXPCWrappedJS::CallMethod [c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp, line 430] PrepareAndDispatch [c:/builds/seamonkey/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp, line 117] SharedStub [c:/builds/seamonkey/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp, line 139] nsControllerCommandManager::IsCommandEnabled [c:/builds/seamonkey/mozilla/embedding/components/commandhandler/src/nsControllerCommandManager.cpp, line 128] nsComposerController::IsCommandEnabled [c:/builds/seamonkey/mozilla/editor/composer/src/nsComposerController.cpp, line 228] XPTC_InvokeByIndex [c:/builds/seamonkey/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp, line 106] XPCWrappedNative::CallMethod [c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2014] XPC_WN_CallMethod [c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1282] js_Invoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 841] js_Interpret [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 2804] js_Invoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 857] js_InternalInvoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 932] JS_CallFunctionValue [c:/builds/seamonkey/mozilla/js/src/jsapi.c, line 3433] nsJSContext::CallEventHandler [c:/builds/seamonkey/mozilla/dom/src/base/nsJSEnvironment.cpp, line 1044] nsJSEventListener::HandleEvent [c:/builds/seamonkey/mozilla/dom/src/events/nsJSEventListener.cpp, line 184] nsEventListenerManager::HandleEventSubType [c:/builds/seamonkey/mozilla/content/events/src/nsEventListenerManager.cpp, line 1220] nsEventListenerManager::HandleEvent [c:/builds/seamonkey/mozilla/content/events/src/nsEventListenerManager.cpp, line 2221] nsXULElement::HandleDOMEvent [c:/builds/seamonkey/mozilla/content/xul/content/src/nsXULElement.cpp, line 3400] nsXULCommandDispatcher::UpdateCommands [c:/builds/seamonkey/mozilla/content/xul/document/src/nsXULCommandDispatcher.cpp, line 391] GlobalWindowImpl::UpdateCommands [c:/builds/seamonkey/mozilla/dom/src/base/nsGlobalWindow.cpp, line 3169] XPTC_InvokeByIndex [c:/builds/seamonkey/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp, line 106] XPCWrappedNative::CallMethod [c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2014] XPC_WN_CallMethod [c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1282] js_Invoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 841] js_Interpret [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 2804] js_Invoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 857] nsXPCWrappedJSClass::CallMethod [c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 1202] nsXPCWrappedJS::CallMethod [c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp, line 430] PrepareAndDispatch [c:/builds/seamonkey/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp, line 117] SharedStub [c:/builds/seamonkey/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp, line 139] nsEditor::NotifyDocumentListeners [c:/builds/seamonkey/mozilla/editor/libeditor/base/nsEditor.cpp, line 2558] nsEditor::PostCreate [c:/builds/seamonkey/mozilla/editor/libeditor/base/nsEditor.cpp, line 336] nsPlaintextEditor::PostCreate [c:/builds/seamonkey/mozilla/editor/libeditor/text/nsPlaintextEditor.cpp, line 365] nsEditorShell::PrepareDocumentForEditing [c:/builds/seamonkey/mozilla/editor/composer/src/nsEditorShell.cpp, line 475] nsEditorShell::EndPageLoad [c:/builds/seamonkey/mozilla/editor/composer/src/nsEditorShell.cpp, line 3065] nsEditorShell::OnStateChange [c:/builds/seamonkey/mozilla/editor/composer/src/nsEditorShell.cpp, line 2831] nsDocLoaderImpl::FireOnStateChange [c:/builds/seamonkey/mozilla/uriloader/base/nsDocLoader.cpp, line 1218] nsDocLoaderImpl::doStopDocumentLoad [c:/builds/seamonkey/mozilla/uriloader/base/nsDocLoader.cpp, line 871] nsDocLoaderImpl::DocLoaderIsEmpty [c:/builds/seamonkey/mozilla/uriloader/base/nsDocLoader.cpp, line 768] nsDocLoaderImpl::OnStopRequest [c:/builds/seamonkey/mozilla/uriloader/base/nsDocLoader.cpp, line 699] nsLoadGroup::RemoveRequest [c:/builds/seamonkey/mozilla/netwerk/base/src/nsLoadGroup.cpp, line 703] PresShell::RemoveDummyLayoutRequest [c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 6768] PresShell::ProcessReflowCommands [c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 6583] ReflowEvent::HandleEvent [c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 6371] PL_HandleEvent [c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c, line 645] PL_ProcessPendingEvents [c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c, line 578] nsEventQueueImpl::ProcessPendingEvents [c:/builds/seamonkey/mozilla/xpcom/threads/nsEventQueue.cpp, line 392]

Comment 49 is about a totally separate bug, it seems (totally different stack, for one thing)

Comment #45 removed. Opening bug back up.

errr. you really marked this bug (temporarily) confidential and even removed a comment just because the operating systems of some talkback users with their email address were mentioned in here!?

it is ok, i requested that, it was my mistake to paste the user's emails in here. thanks a lot myk!

Updating summary with M120B since this has been a topcrasher with Mozilla 1.2 Beta.

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

Adding testcase keyword and making this one topcrash+. Another set of steps to reproduce from duped bug 176690: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; hu-HU; rv:1.2b) Gecko/20021016 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; hu-HU; rv:1.2b) Gecko/20021016 After the "Accept images that come from the originating server only" option is enabled, Mozilla crashes. Reproducible: Always Steps to Reproduce: 1. "Edit/Preferences/Privacy&Security/Images": select "Do not load any images" 2. "OK" 3. Restart Mozilla 4. Load the attached sample HTML file 5. The HTML file contains a link: right click on it and select "Open link in new tab" 6. After the target HTML has been loaded: "Edit/Preferences/Privacy&Security/Images": select "Accept images that come from the originating server only" 7. "OK" It crashes Mozilla. This W2K has service pack 2. Mozilla is the 1.2 beta version. Hope you can reproduce. If not: feel free to contact me. Actual Results: Mozilla crashes. The Mozilla Agent sends in the crash info.

This is a 1.2 topcrash that would be very good to fix before we ship 1.2. Alexandru, can you take a look at this and see if a fix is within reach? Thanks.

i just have to solve a comaptibility issue in the form submission(~3 hrs) and will come to work on this right after that. i haven't tested the steps from comment 56 though, so i cannot say yet how long will it take.

i'm still not able to reproduce this one. jpatel: you mentioned an attached HTML testcase that you used to reproduce the bug. do you have it somewhere around? (the attached cases in this report do not contain images).

on talkback i don't see reports using builds older than 20021111xx.

Alexandru: The testcase I mentioned in comment #56 was not mine. It was the reporter's from duped bug 176690. Here is the link to the html page he used (it's an attachment): http://bugzilla.mozilla.org/attachment.cgi?id=104139&action=view

The url biro_arpad used to reproduce this crash is no longer there: http://prohardver.index.hu/rios2_hir.php?id=1953 biro: have you been able to reproduce this with any other site?

There haven't been public talkback data since November 5. If there were, it would perhaps be easier to tell if bug 150769 really fixed the crash. However, either way, this is probably a duplicate of bug 150769.

> The url biro_arpad used to reproduce this crash is no longer there: > http://prohardver.index.hu/rios2_hir.php?id=1953 I can still access that URL. Maybe from your location it can't be accessed. I found another way to reproduce the crash: 1. start Mozilla 2002101612 2. turn images off ("Do not load any images" in "Privacy & Security" settings), then restart Mozilla 3. visit http://dot.kde.org/1037732247/ 4. right-click the second "screenshots" link (at the top of the article, saying "Check out the full review of K3b including screenshots") 5. select "Open Link in New Tab" 6. when that new page is loaded: "Edit/Preferences/Priv&Sec/Images/Accept images that come from the originating server only" 7. press the "OK" button Crash. I have sent in a crash dump: TB14150976E

Reproduced on Win2k with build 2002111817 from 1.2 branch. TB14153936G. Some web browsing with tabs, then Edit->Prefs->Fonts change font size -> Ok -> Crash.

it would be interresting to know if anyone still gets trunk crashes like reported. if not, then this is a solved bug and it is a dupe of bug 150769.

I can not reproduce this with the trunk 2002112008 or with the 1.2 branch build on Nov 20 at 23:12 (no build ID available). I have tried the KDE example and the testcase.

With Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021120 (SP 2)i can't crash with the KDE example and the HTML testcase.

> Trying to turn off colors with the preferences toolbar That could be me. I keep getting that. Comment 67 and comment 68 indicate being unable to reproduce this on recent builds; momentarily I will download the latest nightly and try my luck. I seem to be able to make it happen pretty often with 1.2 beta, so if it's still an issue I should be able to reproduce it within the hour.

> I seem to be able to make it happen pretty often with 1.2 beta, so if it's > still an issue I should be able to reproduce it within the hour. Sure, I say that and then I can't even make it happen (here at work) with 1.2 beta. I'll have to try it at home (where I've made it happen _many_ times) this evening.

I'm unable to crash mozilla with any of the pages and preference changes here. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a; MultiZilla v1.1.32x) Gecko/20021123

there is one recent talkback report 2002111908 MozillaTrunk Windows NT 5.0 build 2195 2002-11-21 13:15:56 nsQueryInterface::operator() 271d38cd but the stack is a different one (no ref to nsPresContext::PreferenceChanged). I would suggest that if there are no more reports, we lower the importance of this bug or declare it immediately a dup of 150769.

Still can reproduce with 1.2 final, but have to use a different method. Use the method described in comment #64 with the following changes: After that KDE page (http://dot.kde.org/1037732247/) has loaded, save it ("only HTML") to local file "test file.html". The space seems to be necessary in the filename. Then, restart Mozilla 1.2 (images turned off), open this previously created file and follow the steps described in comment #64 (right-click on 2nd "screenshots" link, open in new tab and turn images on). Crash dump: TB14514810H

I just got a crash when changing a pref (page colours) using 1.2 (yeah, I got it before it was pulled and haven't upgraded yet; I have yet to see evidence of the DHTML bug). However, talkback didn't come up (and always had before), so it may not be the same bug.

Bug 150769 was fixed after 1.2 branched, so there's no point to testing with 1.2.

yep, no trunk crashes on talkback with this stack since more than 2 weeks. marking as a dup of bug 150769. if it appears again on talkback please reopen but make sure is the same stack too. there are trunk reports since BZ fixed bug 150769 that have the same stack signature but they don't have the same stack. *** This bug has been marked as a duplicate of 150769 ***