Closed Bug 7862 Opened 25 years ago Closed 25 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 ago25 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.