Open
Bug 799289
Opened 12 years ago
Updated 2 years ago
Trying to install firefox using the stub installer remotely to another machine (network drive) downloads the resources, but gets stuck in the "installing" phase
Categories
(Firefox :: Installer, defect, P5)
Tracking
()
REOPENED
People
(Reporter: jsmith, Unassigned)
References
Details
(Whiteboard: [stubv3+])
Attachments
(1 file)
22.04 KB,
text/plain
|
Details |
Steps:
1. Launch the stub installer
2. Select options
3. Set the path of installation directory to a network drive on another machine you have access to
*** Example: \\JSMITH-07547\Users\jsmith\Documents
Expected:
Not entirely sure of the right behavior here. If installing to network drives is allowed, then we should successfully install and launch firefox. If it isn't allowed, we should error out.
Actual:
The "downloading" phase completes without error and pulls all of resources onto the network drive. However, the installing phase gets stuck spinning infinitely with no end in sight. At a very minimum, we should not spin infinitely.
Reporter | ||
Comment 1•12 years ago
|
||
Not sure entirely what the "right" behavior here is. Robert - Any ideas?
Reporter | ||
Comment 2•12 years ago
|
||
The bad part of this bug is that if you get stuck in the installing phase, you can't close the installer without killing the process through task manager. At a very minimum, we need a way to bail out if installation fails (if that's what happened here at least).
Comment 3•12 years ago
|
||
Could you attach the install.log?
Reporter | ||
Comment 4•12 years ago
|
||
Reporter | ||
Updated•12 years ago
|
Blocks: StubInstaller
Comment 5•12 years ago
|
||
Comment on attachment 669336 [details]
Install log
Looks like it was able to install of the files. Could you try uninstalling, then re-installing, let it continue trying to install for around 10 minutes, killing the installer, and then attach the install.log again along with the uninstall.log located in the uninstall directory.
Reporter | ||
Comment 6•12 years ago
|
||
Will dig into this eventually, but based on the rarity of this use case, I'm flagging this as non-blocking.
Whiteboard: [stub-]
Reporter | ||
Updated•12 years ago
|
QA Contact: jsmith
Updated•11 years ago
|
Whiteboard: [stub-] → [stubv2-]
Updated•11 years ago
|
Whiteboard: [stubv2-] → [stubv2=]
Updated•10 years ago
|
Whiteboard: [stubv2=] → [stubv3=]
Updated•10 years ago
|
Whiteboard: [stubv3=] → [stubv3+]
Comment 8•7 years ago
|
||
Matt, is this a "WON'T FIX" given we don't have the "Options" page on the stub anymore?
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(mhowell)
Resolution: --- → INVALID
Comment 9•7 years ago
|
||
This could still be a real bug, because it is possible for a system to be configured so that our default user-local path happens to point to a network location. But that's a really weird configuration, so I'm giving this one "patches welcome" priority.
Status: RESOLVED → REOPENED
Flags: needinfo?(mhowell)
Priority: -- → P5
Resolution: INVALID → ---
Comment 10•7 years ago
|
||
This probably needs a new bug then, not reopening a new one.
Comment 11•7 years ago
|
||
err... re-opening an old one. :D
Comment 12•7 years ago
|
||
You think so? It's just different STR for triggering the same bug.
Updated•7 years ago
|
Severity: normal → minor
Updated•2 years ago
|
Severity: minor → S4
You need to log in
before you can comment on or make changes to this bug.
Description
•