Windows only, dismissing a dialog will confuse focus. 1) put curson in urlbar 2) bring up the open location dialog 3) dismiss dialog 4) try to type in the urlbar where the cursor is blinking. No text appears. You have to click to get it to work again. This is a side effect of some code danm added to work around a Windows only dialog parenting issue. His code gives the OS windows focus before my focus code fires, messing up the sequence slightly... when I fire focus afterward, the OS doesn't send the appropriate messages because it thinks the window already has focus. I'm trying to work around this by bluring and then refocusing the window in this specific case on Windows only, but it is messy.

Nominating for rtm because this annoys me.

rtm-/future, since this isn't as bad as the similar problem in the editor, and the fix is non-trivial.

Is this because bug 52829 was fixed incorrectly?

This is definitely Mozilla 0.9

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

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

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

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

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

I've seen this too. In Chatzilla, build 2000121904

wow, this is irritating. nominating for beta1.

This also applies to the wallet dialog followed by the security dialog. I'm used to hitting Enter to dismiss the security dialog, but I can't do this after dismissing the wallet dialog. Things get really tricky becuase for some reason my dialogs are currently sizing to content before the content has finished loading...

Very annoying, target mozilla 0.8

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

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

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

I'm adding my comments from bug 64402 because it is another situation where this bug occurs: 1. Type Ctrl-F to open "Find in page" 2. enter something which is *not* on that page, 3. confirm the Alert popping up by pressing enter, 4. notice that you can't type anything in the "find in page" dialog any more, (although the window decoration still suggests keyboard focus)

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

this also sounds a WHOLE lot like bug #53579. Saari, do you agree? If so, i will dup it to this one. anthonyd

IMHO, maybe the two bugs depend on each other, but I think they are about something totally different and should be tested seperately after a fix. Bug 53579 is about Javascript in forms, while I run into this bug all the time when using "Find in page" or "Open Web Location".

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

->moz0.9

I really think the priority should be changed to P1 on this one as it blocks two bugs, and it is very annoying. It is also a mostfreq. You can no longer navigate natively with the keyboard w/o being forced to click in certain places for the focus to be set. Ugh.

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

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

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

Please test this case when verifying this bug. Also note that this happens on Linux whereas this bug and all the other duplicates seem to be Windows only. From bug 67575: If two browser windows are open, the "Find in this Page" dialog will only appear the first time the "Search/Find in this Page" menu is selected or Ctrl+F is used. To reproduce: 0) Start Mozilla. 1) Open a second browser window. I used Ctrl-N. 2) Click in the body of the second window. (This is very important.) 3) Press Ctrl+F or pick the "Search/Find in this Page" menu item. 4) Dismiss the dialog with Cancel. 5) Repeat step 3. The Find dialog does not show. Tested with Mozilla 2001020306 on Linux and the previous day's build on NT4.

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

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

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

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

catfood

This problem is caused by the fix for bug 22658. I'm attaching a patch that makes the 22658 patch less likely to fire. It makes that bug regress a little bit (for instance, any modal window (like prefs) that opens a filepicker window will suddenly have the 22658 problem again, but most situations are still covered (the stacked modal dialogs in Composer, for instance, don't regress)). But it makes this bug happen less often (the Open Web Location dialog, for instance, will no longer cause focus problems when dismissed). I think it's a good compromise for now, since we've been unable to come up with a bulletproof general solution.

r=saari as the best comprimise solution yet. Of course I still think we should let the windows come to front in the wrong order and let people yell at Microsoft instead. Think of it as a forcing function for keeping UI simple...

Is there a base of regression tests that can be run against a build with this patch? Could we bandaid the remaining problem areas somehow?

The best thing I can do is run my focus tests on this on all platforms. As for the remaining problem areas, they're going to be problem areas (with either this bug or the OS windowing bug) unless someone comes up with a way to fix focus to not be broken by the work around (not likely since both danm and myself have attemped various fixes several times). I'm happy to keep looking for another solution, but I think it is probably a black hole and I'd take this partial fix until either danm, myself, or someone else has a whole bunch of free time to throw at this problem.

Danm, I'm giving you this bug since you have the best patch to date. Leave it open once checked in, but put it out past 0.9.

The patch is in. The basic problem still remains, but it'll happen under fewer circumstances. This particular rendition (open web location steals focus from URL bar) *is* fixed. I've gone through some of the dependent bugs; most if not all of them should be fixed now, too, if they were truly just this focus problem. Since technically this bug is fixed, I'm gonna close it. I've opened another (futured!) bug 74053 to find a real, general solution. Remaining problems should be added there as they arise.

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

This solves the Find in Page problem described here. There's still a more general problem with modal dialogs losing focus, but I think that goes back to bug 10000 or something like that.

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

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

[im new at this - forgive me if i am missing something] i have Build 2002030403 on Windows 2000 and this bug still exists - response to any dialog window always shoves Mozilla to the background

Yes, this is back, but this time it's tracked by bug 122765. I will set this bug back to RESOLVED/FIXED and anyone interested in this issue can go to bug 122765.

verified (as is the followup bug)