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

Status: VERIFIED FIXED

(Toolkit :: Application Update, defect, P1)

Description

[Dave Townsend [:mossop]]

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:

Comment 1

[Dave Townsend [:mossop]]

Forgot to mention, the update is applying, when I start firefox manually it is
the new version.

Comment 2

[Dave Townsend [:mossop]]

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.

Comment 3

[James Ross]

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.

Comment 4

[Ben Goodger (use ben at mozilla dot org for email)]

Reassigning to darin, 

Guys, could you tell us what build ids you're updating across? 

Comment 5

[Asa Dotzler [:asa]]

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. 

Comment 6

[James Ross]

(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).

Comment 7

[Dave Townsend [:mossop]]

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

Comment 8

[Darin Fisher]

Thanks guys.  I can reproduce this problem too.  It only happens when I press
"Later" and then quit Firefox, and relaunch it fresh.

Comment 9

[Darin Fisher]

The problem appears to occur whenever Firefox is installed in a directory that
has directory names with spaces.

Comment 10

[Darin Fisher]

Attachment: v1 patch

This should do the trick.

Comment 11

[Flávio Henrique]

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

Comment 12

[Darin Fisher]

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!

Comment 13

[Christian :Biesinger (don't email me, ping me on IRC)]

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?

Comment 14

[James Ross]

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? ;)

Comment 15

[Darin Fisher]

> 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.

Comment 16

[Darin Fisher]

fixed-on-trunk

please test tomorrow's build.