Mozilla loses focus and Z order due to Alert / other dialogs

VERIFIED FIXED in mozilla0.9.9

Status

defect
VERIFIED FIXED
18 years ago
5 years ago

People

(Reporter: bugzilla, Assigned: danm.moz)

Tracking

({regression})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

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
Assignee: trudelle → 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
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: sairuh → pmac
re-summarizing
Summary: Mozilla looses focus due to Finder → Mozilla loses focus and Z order due to Find Dialog
*** 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.
Assignee: bryner → danm
Target Milestone: --- → mozilla0.9.9
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.
.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
*** Bug 125167 has been marked as a duplicate of this bug. ***
Verified (commercial build; 2002-02-21-08-trunk)
Status: RESOLVED → VERIFIED
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.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Summary: Mozilla loses focus and Z order due to Find Dialog → Mozilla loses focus and Z order due to Alert / other dialogs
*** Bug 128493 has been marked as a duplicate of this bug. ***
Adding keywords from bug 128493
Keywords: nsbeta1, regression
*** 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.
Keywords: mozilla1.0
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.
OS: Windows 2000 → All
*** 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
Attachment #72743 - Flags: superreview+
Comment on attachment 72743 [details] [diff] [review]
change order of modal window invisibility and parent re-enabling

r=bryner
Attachment #72743 - Flags: review+
I stand corrected. And learned something new again :)
Keywords: nsCatFood
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. ***
Keywords: nsbeta1nsbeta1+
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
Attachment #72743 - Flags: approval+
  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.
Status: REOPENED → RESOLVED
Closed: 18 years ago18 years ago
Resolution: --- → FIXED
*** 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)
Status: RESOLVED → VERIFIED
*** 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. ***
Posted file Bug still appears
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.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
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.
Attachment #72743 - Attachment is obsolete: true
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.

Blocks: 140346
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
Keywords: mozilla1.1
Updating target to next available milestone while ccing myself. 
Target Milestone: mozilla0.9.9 → mozilla1.2alpha
Never change the target milestone field if you are not the assigned person.
Target Milestone: mozilla1.2alpha → mozilla0.9.9
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.
Status: REOPENED → RESOLVED
Closed: 18 years ago17 years ago
Resolution: --- → FIXED
verified on windows 2k (netscape trunk build: 2002-08-07-08-TRUNK)
Status: RESOLVED → VERIFIED
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.
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.