Closed Bug 302969 Opened 19 years ago Closed 15 years ago

when downloading an update for Firefox, switching to another user account, opening Firefox, and switching back to the first account minimizes all Firefox windows (in the account that was downloading the update) and makes them unminimizable

Categories

(Toolkit :: Application Update, defect)

Product:
Toolkit
Component:
Application Update
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: grantwohl+mozbug, Unassigned)

Details

(Keywords: dataloss, hang, qawanted, Whiteboard: [need testing]) 

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050801 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050801 Firefox/1.0+

When downloading an update for Firefox, switching to another user account,
opening Firefox, and switching back to the first account minimizes all Firefox
windows (in the account that was downloading the update) and makes them
unminimizable.

Reproducible: Always

Steps to Reproduce:
1.Have a computer with Windows XP, fast user switching enabled, and at least two
user accounts.
2.Have app.update.url set to the correct url.
3.Go to Help > Check for Updates....
4.If no updates are available, start over when some updates are available.
5.Start to download the update.
6.Switch to another user account.
7.Open Firefox.
8.Switch back to the user account that was downloading the update.
9.Notice that all Firefox windows in that account are minimized.
10.Try to unminimize a Firefox window.
Actual Results:  
All Firefox windows in the account that was downloading the update were
minimized and could not be unminimized.

Expected Results:  
Firefox should have behaved as normal and allow me to unminimize its windows.
Keywords: dataloss
Flags: blocking1.8b4?
I'm not sure if this is really assigned to the right component...
Tracy - can you reproduce?
Keywords: hang
Unfortunately, I can't test this. My video card doesn't handle account switching
well. Using fast switch, I have to restart when attempting to return to the
original account.
I can try testing this tomorrow. Will report back in the bug.
Whiteboard: [need testing]
waiting on testing from QA to confirm bug and severity

/cb

I was able to config my machine such that the video card wouldn't lock up on me.
 Tested this and got exactly the results as reported.  Step 7) needs to be
clarified. You must launch the same version of Firefox(DeerPark) that you are
attempting to update from the other user.  

Also, switching away then back without launching Deerpark in the second user has
no detrimental affect on the update.

Expected results should be that upon returning to the user that is updating DP
the windows for DP and Software Update (still in progress or at "Restart Deer
Park Now") are *not* minimized. Just as switching went without launching DP in
the second user.
Severity: critical → normal
Status: UNCONFIRMED → NEW
Ever confirmed: true
I don't think a lot of people will be doing this, but still, if there is a way
to lock Firefox from starting during the update, that will probably be enough to
avoid this weirdness.  Can that be easily done?
tracy, can you look into whether or not this happens when an auto-update is
happening. If this happens when background updating is happening, then we
probably need to fix it.
auto-update isn't affected in the same way.  The app isn't minimized.  DP can be
used as usual. But, update download progress has ceased and the resume button is
greyed out. I'm not certain, but I believe that may be another far more critical
bug:  auto-update spins until accessed in Help menu. Or does that have a timer
too?  
Ben,

Can you take a look - is there a more serious issue here with dling (see comment#9)?
Assignee: nobody → bugs
Flags: blocking1.8b4? → blocking1.8b4+
I will take a look on Monday - my computer here at work does not seem to allow
me to create another account or enable fast user switching (work hardware,
locked down by is dept.)
This is going to be a PITA to reproduce given that they can't create new accts
on my system at work so going to try doing it at home. 
Also take a look at bug 307384. I wouldn't say it's a dupe of this bug as
reported, but the steps to reproduce is basically the same.
shouldn't sev=critical if dataloss and hang?
(In reply to comment #14)
> shouldn't sev=critical if dataloss and hang?

I had it like that, but someone changed it.
I was unable to reproduce this. I did the following:

On a WinXP SP2 system, 

1. installed Firefox into c:\firefox
2. set the build id to 0000000000 so that a complete update would be downloaded
3. set the interval between fetches for foreground updates in
nsUpdateService.js.in to 60 seconds
4. started Firefox
5. checked for updates and initiated a download
6. fast user switched to a clean account
7. started firefox
8. fast user switched back to the original account

When I returned, the original account still had firefox as I had left it. 

I also tried this after hiding the update wizard in the original account. 

Triage team: I don't believe this bug is a huge deal. It requires several things
to be going on:

1. from what I've read of the steps to reproduce, you need to run the update in
the foreground then fast-switch to another account and start the same firefox
running there. This doesn't seem particularly likely. 

2. you need to be able to do this in less than the time it takes to download an
update, which is likely to be fairly brief on most systems, especially if the
download is in the foreground. 

3. users who perform the update in the foreground are more likely to be able to
know to close out other active profiles. 

4. I cannot reproduce this particular issue on my development hardware :-)

I say release note saying, "Do not manually check for updates when Firefox is
running from more than one account"... 

That said, running the update process while firefox is running elsewhere on the
system seems like a generally bad idea. On windows, this will cause the
patcher/updater to fail if one admin-level user restarts while another has the
browser running. Darin says his plan for dealing with this is to defer applying
a patch in this case until the next time the browser is started (continually).
This will allow the patch to eventually succeed in application. 
I outlined my solution in bug 306961.
(In reply to comment #16)

I can't reproduce this, either.
marking blocking1.8b5? to cause triage team to revisit this
Flags: blocking1.8b5+ → blocking1.8b5?
ben, comment #17 from darin led us to make that bug a blocker. Do we also need
to block on this one? Are you working on it?
Oops, misread your comment. I see you were suggesting we minus this. If darin's
work over in that other bug helps this out, then we can resolve it. Just in case
this doesn't get fixed, I don't want it to fall off our list. We can dupe it if
it is a dupe.
Flags: blocking1.8b5? → blocking1.8b5+
darin, do you still think that this will be sufficiently fixed by your checkin
for bug 306961? If so, can we resolve this?
Keywords: qawanted
Asa: I don't know for sure, but I think it might help.  I need people to test
out the new builds to see what happens.
If this isn't fixed now, we'll need to try for RC1.
Flags: blocking1.8rc1+
Flags: blocking1.8b5-
Flags: blocking1.8b5+
Grant, can you test the latest branch build
<http://stage.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8/>
and see if this is working for you now?
Flags: blocking1.8rc1+ → blocking1.8rc1-
(In reply to comment #25)
> Grant, can you test the latest branch build
> <http://stage.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8/>
> and see if this is working for you now? 

Asa, it is working for me now.
What's the status on this now? WFM?
Assignee: bugs → nobody
Product: Firefox → Toolkit
WFM per comment 25
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.