Closed Bug 47762 Opened 24 years ago Closed 20 years ago

Installer switches focus to itself repeatedly

Categories

(SeaMonkey :: Installer, defect, P4)

Product:
SeaMonkey
Component:
Installer
Platform:
x86
Windows ME
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.8alpha2

People

(Reporter: cpratt, Assigned: ssu0262)

References

Details

(Keywords: access)

Attachments

(4 files, 1 obsolete file)

patch v1.1
102.39 KB, patch
Details | Diff | Splinter Review
patch v2.0
1.53 KB, patch
dveditz
: review+
asa
: approval1.8a2+
Details | Diff | Splinter Review
(Cv1) <dialogs.c> (1/2)
1.19 KB, patch
dveditz
: review+
benjamin
: approval1.8b4+
Details | Diff | Splinter Review
(Dv1) <dialogs.c> (2/2)
1.19 KB, patch
Details | Diff | Splinter Review 
Build ID:   

ftp://sweetlou/products/client/seamonkey/windows/32bit/x86/2000-08-04-05-M17/

(repacked pr2 bits)

To reproduce:

- Launch the installer
- As Smart Download starts to pull the files down from the server, switch to 
another app to continue your work during the download.

Result: Repeatedly, focus is switched back to Smart Download. This is 
aggravating as you must repeatedly switch back to the other app to continue your 
work. Ideally there would be no focus switching so that you can download the 
.xpi files in the background.
this is commercial installer- changing QA contact
QA Contact: gemal → gbush
This isn't specific to WinME, is it?
As far as I know this happens on all Win32 platforms. IIRC this definitely 
happens on Windows 98 (at least).
Status: NEW → ASSIGNED
Priority: P3 → P4
I'm marking this a dup of 65031.
If this is also a problem with smartdownload please file bug with bugscape, 
since mozilla doesn't use smartdownload.

*** This bug has been marked as a duplicate of 65031 ***
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
This bug was filed almost half a year earlier; therefore, it's not a duplicate 
of a later bug.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
*** Bug 65031 has been marked as a duplicate of this bug. ***
It was instead of moving this to INVALID....:) since smartdownload != mozilla
*this bug is not about smartdownload*

Since my bug has to be a dupe of this bug carrying over comments:
After the new installer (the one without the blue background) the installer 
keeps taken focus when installing. This is because the constant use of "close 
status window, open new status window".

Reproduce:
After pressing Install the installation begins. If you try to set focus on a 
nother application suddenly the installer window gets focus. This is happening 
quite a few times.
It's properbly because the new installer windows dont have any "parent" window 
but are new window, not modular to anything.
This will cause problems for assistive technology users.
Keywords: access
This will cause problems for assistive technology users.
over to Curt.
Assignee: ssu → curt
Status: REOPENED → NEW
Target Milestone: --- → mozilla1.0
only nsbeta1+ bugs can have milestones, resetting to ---
Target Milestone: mozilla1.0 → ---
Depends on: 76467
*** Bug 205303 has been marked as a duplicate of this bug. ***
Resetting milestone.  (This isn't, at least any longer, an nsbeta1+ bug.)

Also changing severity back to normal.  There is no easy workaround for this -
it simply prevents you from doing any other work during the time that the
install takes place.

Reassigning bug to defaults of component, since I believe that the Netscape
people are no longer appropriate.
Assignee: curt → ssu
Severity: minor → normal
QA Contact: gbush → bugzilla
Target Milestone: --- → Future
(In reply to comment #14)
> Also changing severity back to normal.  There is no easy workaround for this -
> it simply prevents you from doing any other work during the time that the
> install takes place.

This may sound like a flame but... for some people "doing any other work" is
actually somewhat important.  Mainly due to this annoyance, I have stopped
downloading the nightly releases and now only upgrade at the milestones, i.e.
you lost one tester.

I fail to understand why there is no easy solution. Surely, it is possible to
create one parent window and make everything else its child?
Attached patch patch v1.0 (obsolete) — — Splinter Review 
This patch will stop the focus stealing.  The only awkwardness is that the GRE
installer runs in "AUTO" mode (show dialogs that does not require user
intevention).  This mode still shows dialogs, which the mozilla installer has
no control over.

One option is to have the GRE installer run in silent mode.  This would be a
trivial patch.

This patch seems to be doing the trick for me.	Could someone try out the
patch?
Attachment #152390 - Flags: review?(dveditz)
r=leaf, i say you check in, and we can test the subsequent tinderbox build.
cc'ing asa for a=, since we're in a freeze.
Flags: blocking1.8a2?
w00t! let's get this in :-)
Comment on attachment 152390 [details] [diff] [review]
patch v1.0

r= (or sr=) dveditz.

ClosePreviousDialog() would be clearer than  CloseLastDialog()--which can mean
"final" dialog--but it's up to you on that.
Attachment #152390 - Flags: review?(dveditz) → review+
Attached patch patch v1.1 — — Splinter Review 
changed CloseLastDialog() to ClosePreviousDialog().
Attachment #152390 - Attachment is obsolete: true
patch v1.1 checked in to trunk only.  Dveditz will be applying the patch to the
various branches.
Status: NEW → RESOLVED
Closed: 24 years ago → 20 years ago
Resolution: --- → FIXED
Flags: blocking1.7.1?
Flags: blocking-aviary1.0RC1?
Attached patch patch v2.0 — — Splinter Review 
I recommend that this patch also be applied.  It makes the gre installer run in
silent mode.

The GRE installer is currently running in "AUTO" mode where it shows dialogs
all dialogs that do not require user input.  Since GRE has it's own installer
(seperate app), it's dialogs will appear in the foreground, taking focus from
whatever app was in the foreground.

Applying this patch will make the GRE installer run in silent mode (no
dialogs).  This allows the Mozilla installer's dialog to be the only dialog
displayed, thus not taking focus from any other app.
Comment on attachment 152585 [details] [diff] [review]
patch v2.0

r=dveditz (or sr= if desired)
Attachment #152585 - Flags: review+
patch 2.0 landed.
Comment on attachment 152585 [details] [diff] [review]
patch v2.0

a=asa
Attachment #152585 - Flags: approval1.8a2+
Flags: blocking1.8a2?
I don't believe this is a problem for the aviary products. Removing aviary
nomination.
Flags: blocking-aviary1.0PR?
I suspect this to have caused bug 264461.
Blocks: 264980
this apparently also caused bug 264980
Product: Browser → Seamonkey
1.7.5 has shipped. Moving request to 1.7.6.
Flags: blocking1.7.5? → blocking1.7.6?
closing down to release 1.7.6  -minus
Flags: blocking1.7.6? → blocking1.7.6-
(1/2) Followup to patch v1.1: (found in bug 264980 comment 29)
1 unused (= leftover) var + 2 nits.
Attachment #188881 - Flags: review?(dveditz)
Dan, (or Sean !):
Could you have a look at my question in bug 264980 comment 42 (and previous) ?
Thanks.
Target Milestone: Future → mozilla1.8alpha2
Comment on attachment 188881 [details] [diff] [review]
(Cv1) <dialogs.c> (1/2)

r=dveditz
Attachment #188881 - Flags: review?(dveditz) → review+
Comment on attachment 188881 [details] [diff] [review]
(Cv1) <dialogs.c> (1/2)

'approval1.8b4=?': (SeaMonkey only)
Trivial Installer code cleanup, no risk.
Attachment #188881 - Flags: approval1.8b4?
Attachment #188881 - Flags: approval1.8b4? → approval1.8b4+
Comment on attachment 188881 [details] [diff] [review]
(Cv1) <dialogs.c> (1/2)


Check in: { 2005-08-03 09:28	neil%parkwaycc.co.uk	mozilla/ xpinstall/
wizard/ windows/ setup/ dialogs.c   1.96 }
Read bug 264980 comment 42 (and previous) for rationale.
Attachment #194029 - Flags: review?(dveditz)
Comment on attachment 194029 [details] [diff] [review]
(Dv1) <dialogs.c> (2/2)

I guess this is not relevant anymore.
Attachment #194029 - Flags: review?(dveditz)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: