seen with gtkEmbed 2001-05-0-22-08 -goto to quicken.com -click on the "Go" button to submit a ticker symbol crash with segmentation fault as the only note in the console.

Works for me in a pull from about 4 hours ago

works for me with the 05-22-06 build. Mpt reported the same findings on IRC. Adam, can we clear this blocker?

I'm doing a fresh pull to be certain. It will be about an hour more before I know if I can reproduce it.

Latest pull does crash on this bug. I'm investigating further.

This bug also affects winEmbed and the ActiveX control but not mfcEmbed. The gtk widget test also seems to be free of the problem. I strongly suspect this is a focus issue (not least from the stack trace below). I can replicate the problem everytime in winEmbed *but* if I deactivate and reactivate the winEmbed window the problem doesn't happen. The deactivation/activation process obviously puts the focus controller into a state where the crash does not occur. CC'ing Ben & Dave for opinion on why this is occurring and how to fix it. NTDLL! 77f9eea9() nsDebug::Assertion(const char * 0x02a26858 `string', const char * 0x02a2689c `string', const char * 0x02a268ac `string', int 0x00000289) line 290 + 13 bytes nsDebug::PreCondition(const char * 0x02a26858 `string', const char * 0x02a2689c `string', const char * 0x02a268ac `string', int 0x00000289) line 434 + 21 bytes nsCOMPtr<nsIDOMWindowInternal>::operator->() line 649 + 34 bytes nsFocusController::UpdateCommands(nsFocusController * const 0x02642d40, const nsAString & {...}) line 132 + 12 bytes nsFocusController::SetSuppressFocus(nsFocusController * const 0x02642d40, int 0x00000000, char * 0x02513b9c) line 416 + 29 bytes nsDocShell::SetupNewViewer(nsDocShell * const 0x01083530, nsIContentViewer * 0x035df6c8) line 3601 nsWebShell::SetupNewViewer(nsWebShell * const 0x01083530, nsIContentViewer * 0x035df6c8) line 347 + 13 bytes nsDocShell::Embed(nsDocShell * const 0x01083554, nsIContentViewer * 0x035df6c8, const char * 0x0251989c, nsISupports * 0x00000000) line 3128 + 23 bytes nsWebShell::Embed(nsWebShell * const 0x01083554, nsIContentViewer * 0x035df6c8, const char * 0x0251989c, nsISupports * 0x00000000) line 376 nsDocShell::CreateContentViewer(nsDocShell * const 0x01083530, const char * 0x0012fc30, nsIRequest * 0x02704ee0, nsIStreamListener * * 0x0012fc80) line 3407 + 32 bytes nsDSURIContentListener::DoContent(nsDSURIContentListener * const 0x01083998, const char * 0x0012fc30, int 0x00000007, nsIRequest * 0x02704ee0, nsIStreamListener * * 0x0012fc80, int * 0x0012fc14) line 119 + 33 bytes nsDocumentOpenInfo::DispatchContent(nsIRequest * 0x02704ee0, nsISupports * 0x00000000) line 350 + 93 bytes nsDocumentOpenInfo::OnStartRequest(nsDocumentOpenInfo * const 0x028d9598, nsIRequest * 0x02704ee0, nsISupports * 0x00000000) line 219 + 16 bytes nsStreamListenerTee::OnStartRequest(nsStreamListenerTee * const 0x03518a18, nsIRequest * 0x02704ee0, nsISupports * 0x00000000) line 14 nsHttpChannel::ProcessNormal() line 435 nsHttpChannel::ProcessResponse() line 366 + 8 bytes nsHttpChannel::OnStartRequest(nsHttpChannel * const 0x02704ee4, nsIRequest * 0x027860f8, nsISupports * 0x00000000) line 2000 + 11 bytes nsOnStartRequestEvent::HandleEvent() line 108 + 53 bytes nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x035185dc) line 64 PL_HandleEvent(PLEvent * 0x035185dc) line 590 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00fa12e0) line 520 + 9 bytes _md_EventReceiverProc(HWND__ * 0x001a0322, unsigned int 0x0000c144, unsigned int 0x00000000, long 0x00fa12e0) line 1071 + 9 bytes USER32! 77e148dc() USER32! 77e14aa7() USER32! 77e266fd() main(int 0x00000001, char * * 0x00357ac8) line 171 + 9 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! 77e992a6()

No problems on LINUX Mozilla 0.9 Mozilla/5.0 (X11; U; Linux 2.2.14-5.0 i686; en-US; rv:0.9) Gecko/20010505

yes, focus!! I can't even get the cursor to land in the text input field associated with the "Go" button.

I am seeing this on mfcembed 2001-05-23-09 is this the same as bug 82359 ?

returning to blocker because it is.

The stack trace on the other bug suggests that is another problem. This one appears to be something to do with loading new content while the input entry field (just before the Go button) is the current element but the browser window is not active.

I saw this same crash (null |window| at that line) in mozilla on Linux, running the top100 urls in the pagecycler (./mozilla -f <file-with-a-url-per-line>), I think on the transition from the first to the second URL (http://www.yahoo.com/ to http://www.netscape.com/ ).

The crash is occuring because the UpdateCommands method in the focus controller is accessing the document while the content viewer and window are being torn down. This patch fixes the crash by setting the element with focus to nsnull just before SetSuppressFocus is called so that there are no commands (elements) to update. Hyatt can you comment on whether this is the correct way to fix the problem?

Possible dupe of 82359?

I don't believe this is a dup of bug 82359. This problem here is the focus controller is attempting to notify command handlers about the focus element, assuming that the document has a window when it is mid-way through being torn down. My patch removes the focus element during tear-down so it doesn't hit this piece of code. Ultimately the proper solution would be to get focus working proplerly in the embedding apps so every is in the state they expect to be in.

cc'ing bryner + saari.

Suppression of the focus controller is intended to preserve the focus state of the app for later retrival, like when you reactivate a window for example and expect focus to be where it was. To null out the focused element before supression defeats that. In this case, it is to preserve content area focus across link traversal as is explained in the large comment hyatt added above your patch. So this will break link traversal focus. I'm curious why this behaves differently in different embeddors. When a document gets torn down across link traveral shouldn't change, especially between winembed and mfcembed.

Is this really "worth" having the tree closed for? There's no traction :(

Actually nulling the focused element should be fine and safe. It's nulling out the focused window that would be wrong. I don't see any problem with this.

Er, yeah that is safe in this case, but not in all cases. I still want to know why the document destruction is different.

<sheriff> Any progress on this? Currently this is the only bug keeping the Mozilla tree closed... </sheriff>

How about checking this in and fixing the crasher, then you can fix this the correct by making it block 0.9.1?

r=saari for the patch

sr=hyatt Actually, I think this patch is good. I have to do the exact same thing for a similar situation in the presshell. It makes sense that you'd go ahead and null out the focused element when you bring in a new page.

Who's checking it in?

Fic checked in for Adam Lock, since pollmann told me he is most certainly asleep Hope this was OK with Adam.

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

Checkin was fine by me, thanks everyone

This fix caused bug 82710.

still seeing on gtkembed 2001-05-29-08

Note: We are only seeing this on the embedded product not mozilla or commercial.

-> trudelle for triage.

I ran a purified version and got FMW (free memory write!) loading quicken.com but did not crash when clicking on the 'Go' button with/without a stock symbol I opened bug 83163 for the FMW.

There is a new patch for this against bug 82710: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=36305

->saari

patches are going to 82710, this should be a dup of that bug, marking so. *** This bug has been marked as a duplicate of 82710 ***

note, embed focus problem is now bug 83201.

this wasn't fixed by the patch for 82710. And this crash existed before those error messages appeared. reopening...still a blocker

gtkEmbed works fine for me with the patch applied

locka, please be specific about which patch, we're pointing at other bugs, other patches, etc., let's just spell it out so people don't get confused. Also, is this still embed-only?

I cannot get focus to the text field at quicken.com with the current linux gtkEmbed build. Note, this is also the case with http://bugzilla.mozilla.org. If this is the case, we should change the bug to say bugzilla, that'll get more people worried about it.

->p1/0.9.1

changed description. this happens with any form submittal button.

The embedding tarball certainly crashes but I have been unable to reproduce the problem in my builds at all. I just tried a fresh build with the fix and it works as expected. I have tried reproducing the problem using the gtkEmbed from mozilla/dist/bin and from mozilla/dist/Embed/ without success. I even tried changing the focus settings in my Sawfish Window Manager to see if that triggered it but it didn't. Chris McAfee also tried with a clean optimized build and couldn't reproduce the problem either. This suggests the most likely reason for the crash is a packaging issue but I can't think what it could be.

resummarizing to embed-only, please update if this is seen in seamonkey.

I think I've narrowed down the cause a bit. I diffed my embed build against the tarball and noticed that the nightly embedding tarball contained PSM. So I deleted all the psm stuff (libs, chrome, overlays), rebuilt component.reg and now it runs. Can anyone think of why this may be?

Further investigation reveals PSM contains an object called nsSecureBrowserUIImpl which implements nsIFormSubmitObserver. If this is registered and listening to form submits, it is possible that this is causing the crash. This could be because gtkEmbed is not sufficiently able to pose a confirmation dialog that PSM expects to show. I believe the workaround for the time being is to remove the PSM code from the embedding manifest. Patch follows.

r=valeski. cc'ing chak so he knows there are linux issues w/ the psm dist.

Reassigning to me

fix checked in, marking so.

verified fixed with gtkEmbed 2001-05-31-08

reopening... I am seeing this crash again on linux gtkembed 2001-07-02-06 clicking go at www.quicken.com causes crash with segmentation fault

Isnt this crash related to chris watersons checkin for viewer to enable focus for form elements (sorry Chris for pointing with my finger)

Are you sure this isn't the same as bug 90164?

bernd: I doubt it. The code I changed should only be compiled into the viewer app.

For lack of a stack on this bug, I'm going to mark this fixed to get it off the rader since it was probably reopened because of bug 90164 rather than a reoccurrence of this bug. New crashes should generally be filed as new bugs rather than reopening bugs that happened to occur on the same action, unless clear similarities are detectable (i.e, the stack trace is the same).

Er, actually, undoing that since I missed the date of reopen (I thought it was today). Why did this just appear on the blocker list today, anyway? I don't see anything in "View Bug Activity" that would cause that. But is this bug still known to be current?

It still happens, but it is difficult to produce a stack trace because gtkEmbed behaves differently under gdb. Also the I suspect the problems with horked manifests identified in bug 83393 are contributing to this problem too.

Downgrading to critical to get tree open.

I can't get gtkEmbed to render www.quicken.com while running gdb. If someone else can duplicate the crash under gdb can you attach a stack trace?

This works in TestGtkEmbed. Since we're proposing to ditch gtkEmbed in favor of TestGtkEmbed, I suggest marking this invalid. Marking dependency of bug 90256, the move-to-TestGtkEmbed bug.

Milestone reality check.

I am seeing this segfault crash on my machine with TestGtkEmbed. Can anyone else verify on another machine. Today was the first time I've run TestGtkEmbed. It crashes on form submit at quicken.com, same as gtkEmbed.

-> mcafee. adam's gone for another couple weeks.

actually, over to blizzard. sorry.

This is working for me in my local opt build. Are you sure this isn't a packaging issue? Stack trace? I can't reproduce.

this is what I see on the console at crash time: Program received signal SIGSEGV, Segmentation fault. 0x40c98eeb in nsKeygenFormProcessor::Init () from /u/twalker/memtest/bin/embed/components/libpipnss.so

I don't see an Init method for that class. How strange.

couldn't reproduce in 8/1/01 mozilla.exe or mfcembed. clicked on Go button with several symbols, one symbol, or blank and didn't see any crash.

changing Summary to specify embed app. for this happens on linux based TestGtkEmbed and gtkEmbed only. Also putting back to smoketest blocker status. this bug is _not_ logged against windows mfcembed.

I still can't reproduce this.

Can someone who can reproduce this take the bug? This is a blocker assigned to a person that can't reproduce the problem.

downgrading to critical to get tree open...

I've reproduced this bug in another application. This patch fixed it for me in that application and I'm pretty sure that it's the same. javi, can you please review?

patch looks good to me, r=mcafee

r=javi

sr=tor

I don't have permission to check this in. Over to javi.

Patch checked in.

okay, this didn't crash on build 2001-08-13-06-trunk. But now the security dialogue that pops up on form submit is missing the buttons allowing the user to proceed with the form submit. Is there a bug open for this? verified this crash is fixed

Tested against Linux build 20011121. No crash in TestGtkEmbed.