Using 19990520 buids the browser window keeps popping up to the front of the window you are using. 1. Launch apprunner. 2. Open Editor or Messenger 3. Wait about a minute, you will see the Browser window come up to the front and have focus. Just started happening with this build.

Note: this is for Windows only.

chofmann- can you reassign? We're not sure who this goes to.

Still happens with 19990521 win32 build

One possibility is that this is happening exactly when the sidebar re-loads content. Maybe "onload" has default behavior to bring the window to the front? Try this: sidebar-browser.rdf from mozilla/dist/win32_d.obj/bin/res/rdf (so the sidebar won't load any content), and see if the problem persists.

This sidebar loads the Tinderbox panel every minute. Would this cause the browser to pop to the front?

It is the flash panel (or maybe the reload of the tinderbox panel) in the sidebar that is causing this. However, the problem seems to be that we _always_ call window->SetFocus() when a new webshell gets embedded. Here is the stack trace. nsWindow::SetFocus(nsWindow * const 0x04420724) line 900 DocumentViewerImpl::MakeWindow(void * 0x00150a76, const nsRect & {...}, nsScrollPreference nsScrollPreference_kAuto) line 739 DocumentViewerImpl::Init(DocumentViewerImpl * const 0x03fe6e70, void * 0x00150a76, nsIDeviceContext * 0x03ef0400, nsIPref * 0x00ec3890, const nsRect & {...}, nsScrollPreference nsScrollPreference_kAuto) line 341 nsWebShell::Embed(nsWebShell * const 0x03eefc40, nsIContentViewer * 0x03fe6e70, char * 0x0463f530, nsISupports * 0x00000000) line 765 + 69 bytes nsDocumentBindInfo::OnStartBinding(nsDocumentBindInfo * const 0x0463f4e0, nsIURL * 0x0463f910, char * 0x03fcdb70) line 1428 + 36 bytes OnStartBindingProxyEvent::HandleEvent(OnStartBindingProxyEvent * const 0x03fcd980) line 507 StreamListenerProxyEvent::HandlePLEvent(PLEvent * 0x03fcd984) line 472 + 12 bytes PL_HandleEvent(PLEvent * 0x03fcd984) line 491 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00ee58c0) line 452 + 9 bytes _md_EventReceiverProc(void * 0x155a0528, unsigned int 0x0000c0a6, unsigned int 0x00000000, long 0x00ee58c0) line 868 + 9 bytes USER32! 77e71268() I'd comment it out, but, see comments at: http://lxr.mozilla.org/seamonkey/source/layout/base/src/nsDocumentViewer.cpp#73 4 Reassigning to rickg to parcel out as appropriate. This is a generic layout problem. FWIW, it seems that this is fundamentally wrong, and we need to figure out another way to ensure that page up/page down work. You can't call SetFocus() every time a document finishes loading, or else you'll end up with races between documents.

adding myself to the Cc: list of this bug to stay in the loop...

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

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

adding myself to this bug; changing Platform/OS to ALL since a side effect of the behavior waterson describes happens on Mac as well (edit field loses focus while typing in it). I think the priority should be upped to P2 because it is so difficult to file bugs in 5.0 when you keep losing focus.

need to move this to M7. we will release note how to disable the sidebar features that expose this bug.

Nisheeth -- let's start with the assumption that the webshell call to setfocus() is the culprit. This is an important bug, so please take a look as soon as you can.

For now, I am going to comment out the call to SetFocus() within nsDocumentViewer::MakeWindow(). All the places in the embedding application which need to set focus on a particular window can call the SetFocus() method on the webshell corresponding to that window. Any objections?

Adding rickg and waterson to the cc list so that they can respond to my earlier comment.

Makes sense to me.

The fix was checked in on 6/3. Marking bug resolved.

Fixed in the June 09 Build.