Closed Bug 300404 Opened 19 years ago Closed 19 years ago

Firefox fails to start immediatly after software update (when 'Later' option is chosen)

Categories

(Toolkit :: Application Update, defect, P1)

x86
Windows XP
defect

Tracking

()

VERIFIED FIXED
mozilla1.8final

People

(Reporter: mossop, Assigned: darin.moz)

References

Details

(Keywords: verified1.8)

Attachments

(1 file)

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

After firefox has downloaded an update it restarts to apply it. I see the
progress bar as it applies the update then this window closes but firefox does
not start.
I can start firefox manually.
This has happened twice out of about eight times I have updated.


Reproducible: Sometimes

Steps to Reproduce:
Forgot to mention, the update is applying, when I start firefox manually it is
the new version.
After another couple of updates it looks like this always happen if you dont
choose to update immediatly, but restart firefox yourself at a later time.
Yeah, that matches the issue I've found. If you let Software Update restart
Firefox, it applies the update and starts Firefox properly. If you say Later,
then quit Firefox yourself, the next start applies the updates but does not
start Firefox.

This happened with my update to build 20050722, and has been occuring for every
update I have tried using Later for the past few weeks.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reassigning to darin, 

Guys, could you tell us what build ids you're updating across? 
Assignee: nobody → darin
This happens on the latest trunk builds of Firefox and Thunderbird. If you delay
restarting, then close out Firefox and restart it, the update exe runs but
Firefox is not launched. If you let update shut firefox down and restart
automatically to trigger the update.exe, then Firefox is launched at completion
of the updater. 
Flags: blocking1.8b4+
(In reply to comment #4)
> Guys, could you tell us what build ids you're updating across? 

As the bug report says, any updates between nightly builds - be it one day or
three days - for a few weeks has had this problem, and may have always been like
this (can't remember).
Blocks: 290390
Severity: normal → critical
Status: NEW → ASSIGNED
Target Milestone: --- → Firefox1.1
As an example, just saw this when updatin from:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050723
Firefox/1.0+ ID:2005072306
To:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050726
Firefox/1.0+ ID:2005072606
Priority: -- → P1
Thanks guys.  I can reproduce this problem too.  It only happens when I press
"Later" and then quit Firefox, and relaunch it fresh.
Summary: Firefox fails to start immediatly after software update → Firefox fails to start immediatly after software update (when 'Later' option is chosen)
The problem appears to occur whenever Firefox is installed in a directory that
has directory names with spaces.
Attached patch v1 patchSplinter Review
This should do the trick.
Attachment #190743 - Flags: review?(benjamin)
Attachment #190743 - Flags: review?(benjamin) → review+
I'm afraind that this occurs even if we choose Restart Firefox now.

Today, after updating to "Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b4)
Gecko/20050727 Firefox/1.0+" I must open firefox directly from my start menu.

From weeks this behavior happens even choosing Restart Firefox Now.
In fact I never used the Later buttom and always see this happens.

Clickin in Restart buttons means, to me, that after updating the software
Firefox should start auto.

Thank you.

Flávio
Flávio: Thanks for the additional info.  I suspect that the current patch will
still help.  Let's re-test once it has been checked in and new builds appear
(usually one day after a patch is checked-in).  Thanks!
Attachment #190743 - Flags: approval1.8b4?
Attachment #190743 - Flags: approval1.8b4? → approval1.8b4+
Comment on attachment 190743 [details] [diff] [review]
v1 patch

what if short path names are disabled? why not instead do stuff in a way that
can handle spaces?
There is already dodgy short-path-name stuff in the XRE apprunner restart code
(which breaks for UNC paths, as I found) so why complain now? ;)
> what if short path names are disabled? why not instead do stuff in a way that
> can handle spaces?

Because the Microsoft CRT does not handle paths with spaces very well.  I agree
that this is unfortunate since it won't work with UNC paths, but as James
correctly points out we have a problem there anyways with app restart.  I think
a separate bug should be filed on eliminating the need to convert to short paths.
fixed-on-trunk

please test tomorrow's build.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Keywords: fixed1.8
Status: RESOLVED → VERIFIED
Keywords: fixed1.8verified1.8
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: