Closed Bug 7862 Opened 25 years ago Closed 24 years ago

When prefs window is left, focus switches to other app

Categories

(SeaMonkey :: Preferences, defect, P2)

x86
Windows NT

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 6058

People

(Reporter: cpratt, Assigned: law)

References

Details

build id: 1999060909
platform: windows nt

to reproduce: open the prefs window. click cancel. result: you are switched to
another currently running application. expected result: you remain in apprunner.
Assignee: shuang → matt
Re-assign it to matt for fixing
Target Milestone: M9
Matt, is this something you can fix or do you need Matiskella help on this?
Assignee: matt → davidm
Target Milestone: M9 → M10
i'm not sure what is causing this.
David, can you take a look?
Assignee: davidm → law
since it is on a PC I am going to pass this on to bill.
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
This was most likely due to transitional behavior in the modal window support in
the windowing/toolkit area.  In any case, the behavior is no longer evident and
closing preferences leaves focus on the browser window from which it was opened.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This problem has not gone away in the 1999111016 M11 build of seamonkey.
Reopening and clearing resolution. (I used Windows NT - clicking Cancel once
again switched me to another application.)
Summary: When prefs window is dismissed, focus switches to other app → When prefs window is left, focus switches to other app
Bug 15278 is the other side of this - clicking on [Ok] has the same result.
It looks like leaving the prefs dialog results focus switching to whatever app
had focus immediately before the Mozilla app the dialog was summoned from,
no matter how the prefs dialog is left.

Changing "dismissed" to "left" in summary to reflect that.

Works incorrectly with:
1999-11-09-11-M11 nightly binary on Windows NT
Every other nightly binary checked for at least two weeks.
Target Milestone: M11 → M12
moving off to m12 to figure out why cpratt still sees the problem
Target Milestone: M12 → M13
This is really annoying but not a M12 stopper.  Moving to M13.
Priority: P3 → P2
Target Milestone: M13 → M15
Not required for beta 1.
spam: in my testing realm, so reassigning qa contact to me, en masse.
QA Contact: cpratt → sairuh
This looks like a DUP of bug 6058, "Closing the prefs window activates the wrong 
browser window", ASSIGNED to danm@netscape.com, M15, although a clearer 
description can be found in bug 22685, "[PP] Closing some dialogs activates the 
wrong window", which presents the general case for the Prefs dialog and other 
modal dialogs that have been misbehaving this way. 

In any case, this seems to be working in 2000-01-22-08-M14 on NT.
*** Bug 15278 has been marked as a duplicate of this bug. ***
Ooops, typo. The bug that clearly describes this problem for multiple 
dialogs is bug 22658, not 22685.
*** Bug 23946 has been marked as a duplicate of this bug. ***
Bulk move of all Pref UI component bugs to new Preferences component.  Pref UI 
component will be deleted.
Component: Pref UI → Preferences
*** Bug 28179 has been marked as a duplicate of this bug. ***
*** Bug 32935 has been marked as a duplicate of this bug. ***
Depends on: 22658
*** Bug 32535 has been marked as a duplicate of this bug. ***
*** Bug 33796 has been marked as a duplicate of this bug. ***
Move to M16 for now ...
Target Milestone: M15 → M16
*** Bug 36052 has been marked as a duplicate of this bug. ***
I know this bug has been around for a while, but ... I can not see any difference 
at all between this bug and bug 6058.


*** This bug has been marked as a duplicate of 6058 ***
Status: REOPENED → RESOLVED
Closed: 25 years ago24 years ago
Resolution: --- → DUPLICATE
It isn't the same bug... maybe. The other bug says that closing the prefs window 
returns you to a mozilla window, albeit the wrong one. This bug says that 
closing the prefs window switches you to a completely different application. 
Which is it? Leaving it to sairuh to decide which is true / still happens... 
thanks!
verif. hunh.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.