Just saw this on my cvs build on Linux. If I middle click on a link to open it in a new tab (new tabs load in background is _off_), then switch to another window, the original window will pop back to the front when the page loads (when painting is unsuppressed). It's probably a regression from a recent fix, most likely bug 170811.

hm, i cannot seem to repro this with yday's build (2003.04.03.05, post-fix for bug 170811) on linux rh7.2 (i know, oldish o/s --could it be o/s specific?) how did you switch windows? by mouse-clicking? i tried going btwn a browser and mailnews window, and btwn two browser windows, but didn't see the original window pop back to the front. (also couldn't repro on mac os x, 2003.04.04.10, fwiw.)

It happens via either clicking or alt-tabbing, but only if the window I switch to is not a Mozilla window.

aha, with that info, i now see the problem on linux rh7.2. however, i cannot repro this on os x --does it occur on win32?

Seems to be linux-only. I do get an assertion about focus controller suppression on win32 though. Also, updating the summary to reflect that the window doesn't actually steal focus, but is raised.

This is another case where we get a focus event and the document has not yet been reflowed. Since we don't dispatch the deactivate event to the window, the focus controller still thinks it's active. There's currently a hack in PresShell::HandleEvent for dealing with this case for NS_GOTFOCUS. Instead of adding to that, what I'd like to do is not just bail in the case where we can't get a target frame. We should still dispatch the event to the document and the window. It appears to be pure luck that this doesn't happen on win32 (it looks like it should... nsWidget::SetFocus is getting called, but apparently doesn't do anything. I don't know why.

*Maybe* related: bug 199999

Fix checked in (from bug 201996).

vrfy'd fixed using 2003.05.12 builds in linux rh8.0, win2k and mac 10.2.6.