From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.8+) Gecko/20020128 BuildID: 20020128 Press CTRL + F. Search for a word you know does not exist in the document. "The text you entered was not found" pops up. Press OK, then press Cancel on the Find dialog and Mozilla looses focus. Reproducible: Always

I can confirm this, using 2002 01 30 03 / win2k. Very annoying indeed! May the summary should be re-phrased? Mozilla not only looses focus, but lowers the Z level of the window, i.e. when the dialog "Find in this Page" is dismissed the Mozilla window is placed _behind_ another window (often a non-Mozilla one).

It seems that this only happens if the "Alert" dialog "The text you entered was not found" has been issued.

Been seeing this today. Win XP Pro build 2002013003. There's one thing that really bothers me about searching. If you click on a browser window (which I do all the time to get focus away from a form or something), then any search starts from that point, not from the beginning of the document like it does in IE. I like the behavior in IE better where it only starts from a point if there is actually something (text) selected there. If there's no visual clue of what is selected you don't have any idea where that point is! More than once, I've had to open IE just to verify a search result. Combine that with this bug and you can get a pretty confusing situation. Sorry for the off-topic rant. I'm sure there is a reason for that search functionality.

Blake, there is another bug discussing the behavior you describe, though I don't have the number handy. (If you want to search for it, I'm probably cc'd, and the summary probably has 'find' in it) I agree that we should only start the search within the document if there is a selection, because there needs to be an obvious visual cue. Hidden find cursors are not in most user's model of how the browser works. ->bryner

blake: bug 87037 all: If it helps track down the problem, another way to easily reproduce this is to bring up the Find dialog, switch to another application, switch back to Moz, and cancel the Find. The application that was switched to takes focus.

Confirming. Win2k 2002020409

re-summarizing

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

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

I think this problem also occurs with the certificates alert box. When visiting the URL in bug 124742, I followed the reporter's step to reproduce. I could not repoduce the crash, but at the Submit Resume page, I clicked the Next button and a certificate dialog was shown. After viewing the problem certificate and accepting it, the dialog was dismiss, and mozilla was dropped in the z-order. Since I've accepted the certificate I can't reproduce the z-order behavior, and I don't know of any other certificate test cases off hand. Hope this helps.

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

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

stacked dialog focus regression. mine.

code to activate the parent was shot in the back a few revs ago. this puts it back. Note this only fixes the problem as originally reported. Dean's observation from comment 5 remains unfixed. There was a time when that too worked, but a bunch of evil focus regressions (see bug 54936) caused us to partially back that out, and the comment 5 situation was one of the casualties.

.

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

Verified (commercial build; 2002-02-21-08-trunk)

yeah, worksforme now.

I see this same behavior with the dialog for subscribing to newsgroups. Should this be re-opened, or a new bug filed?

OK, not just the Subscribe Dialog. Also Alerts, such as when you type in a URL for a host that does not exist. Re-opening and re-summarizing, based on comment #2 If this is a different bug, a new one can be opened I guess.

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

Adding keywords from bug 128493

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

In Mail&News, any 'standard' alert like unsubscibe, move to next folder etc causes Mozilla to lose focus. Very annoying.

I'm seeing this on build 2002030316, on the 0.9.9 branch, on Windows 2000. It's happened to me on a "new unsigned site certificate" dialog, all javascript alerts, the "Mozilla can remember this password" dialog, and all login dialogs, whether login is successful or not. This is *without* switching apps while the dialog is open, as mentioned in <a HREF="#c5">comment 5</a>; it seems to happen with every dialog, no matter what. If I find exceptions, I'll post them.

seeing this with mail/news (any popup), browser -- "Find in this page" (when something I'm searching cannot be found)

How about r= and sr= on that patch? /be

Bug 128874 is a multi-OS bug that is probably a dupe of this. If so, someone please change from W2K and dupe bug 128874.

Brendan: that patch has already been applied. It doesn't cure the situation.

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

Win32 installer build 20020227 worked fine and 20020228 is busted.

Weird. It seems to me that backing out the change done in bug 54936 (only took out the lines from nsXULWindow::ActivateParent()) fixes this, which is funny, because 54936 was supposed to do so. I gather that the modal window system has changed recently, right? Could it have affected this? I also tried many of 54936's blocked bugs and didn't notice problems there either (with this backed out version). Hmm?

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

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

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

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

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

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

This looks like the same problem, but actually it's completely different. This regression was caused by a change in the order in which a modal window is made invisible as it's destroyed and the modal window's parent is re-enabled. This patch puts it back the way it used to be and adds a big "keep it that way" comment to reduce future confusion.

Comment on attachment 72743 [details] [diff] [review] change order of modal window invisibility and parent re-enabling sr=jag

Comment on attachment 72743 [details] [diff] [review] change order of modal window invisibility and parent re-enabling r=bryner

I stand corrected. And learned something new again :)

This bug seemed to emerge just after the fix for bug 116074 was checked in. Could they be related?

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

Comment on attachment 72743 [details] [diff] [review] change order of modal window invisibility and parent re-enabling a=asa (on behalf of drivers) for checkin to the 0.9.9 branch and the 1.0 trunk

Patch is in 0.99 and trunk. Ere: the fix for bug 22658 is a brute force thing; a little too brute. The fix for bug 54936 makes it a little less brute. Cranking up the bruteness by unfixing 54936 would indeed have fixed this problem and a couple of others as well, but also would have rained down focus hell. Thanks for taking a look, though. Cormac: no, actually I caused this regression with the patch for bug 126786. The asymmetry of parent enabling bothered me. I probably knew better once. Now the asymmetry is flanked by massive comments encouraging me to keep it that way. And 126786 is no worse off.

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

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

Verified on windows 98 (commercial build: 2002-03-07-05-trunk)

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

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

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

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

Build 20020307 Win2K: almost perfect, although I noticed the following: - one Navigator window and Mail & Newsgroups open - put invalid url to the url bar - focus Windows desktop - wait for the alert - click Ok --> Mail & Newsgroups window is focused. This seems to happen always if focus is on desktop when the alert fires. Well, I think it's not so bad because Windows desktop doesn't have focus so often and this didn't seem to happen if the focus was in another program.

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

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

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

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

Try this testcase, every 3 seconds you will get an alert. Press ok at least one time and then ALT + TAB to another application. Now when you go back to mozilla every time you press OK Mozilla will loose focus.

Reopening bug, run testcase to see that bug still appears.

I don't see the mentioned behavior on the M0.9.9 on linux.

Cannot reproduce with latest build on Windows Xp. Maybe Windows 2000 only? I am using Windows 2000 SP2 build 20020313.

I'm using Win2000 with SP2 with mozilla 0.9.9 BuildID: 2002031104 and it doesn't happen anymore.

Running the test in comment 59 shows me the bug. System is Win2000 Server SP1 with Mozilla build 2002031104.

I can reproduce a similar bug to that in comment #59. 1. File/Open File 2. Start Notepad 3. Cancel the open file dialog 4. File/Open Web Location 5. Start Notepad again 6. Cancel the open web location dialog After step 3, control returns to the browser window. But after step 6, contorl switches to notepad.

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

In Linux, with 0.9.9 (including 03/20 nightly build) open mail application. Mail loads, then the Z-Order is altered putting the browser up. While the mail application is running, the browser acts flakey. clicking on a link will cause that page to load, then rapidly load to the FIRST page in the current browser window cache. You can then click the back button to visit the page you wanted. Behavior goes away when the mail window is closed. Behavior Page A - Start page. Assume history of A -> B -> C On Page C click to D. Page D appears then rapidly cycles back to A A -> B-> C -> D -> A is the current history. Didn't work this way in 0.9.8. Assume issue was created with Z-order changes.

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

you could also see a variation of the other focus bugs out there.. one is Mail/News steals focus which is a totally seperate bug than the Z-order bug.

Comment on attachment 72743 [details] [diff] [review] change order of modal window invisibility and parent re-enabling obsoleting checked in patch.

Bug still appears... in the mail application, turn the side bar on, go to the history tab. Close it. Reopen mail (so that it queries the history section), z-order problem still happens. But if you change the mail sidebar tab to Search, close and reopen, the Zorder problem doesn't happen.

I see this behaviour (linux, build 20020424): - Open the Mail component; - Turn on the sidebar (if it is already on, click F9 twice); Immediately, the Browser is raised in front of the Mail window.

Easy way to reproduce: 1. When Quicklauch is active, rightclick and select Disable Quicklauch. 2. Mozilla pops up an alert informing you how to reactivate 3. Press OK --> Moz loses focus

Updating target to next available milestone while ccing myself.

Never change the target milestone field if you are not the assigned person.

Okay, lesson learnt, and appologies for any offense caused. But is there really any harm moving it forward when the target is clearly passed? And moreover what is the point changing it back to that milestone when someone will just have to move it forward again? My thinking was that it would simply draw the attention of the owner and perhaps save them from moving it forward if 1.2a happened to be what they wanted. They can easily push that back even further if needed. Anyway, next time I will just comment. Sorry ... :(

worksforme using winxp and 1.1a

I think we should mark this bug as resolved again. Comment 59 is bug 155002, which is a much more manageable bug than this beast. If any other issues come up, new bugs can be filed if they aren't already.

I agree, Dean. Resolving as fixed due to comment 78.

verified on windows 2k (netscape trunk build: 2002-08-07-08-TRUNK)

OK, so should I file a new bug to cover comment 65?

Neil: doesn't hurt, although it may very well be a dupe of bug 155002.