MacLaunchHelper LaunchChildMac doesn't propagate environment to child

RESOLVED WONTFIX

Status

Toolkit Graveyard
XULRunner
RESOLVED WONTFIX
11 years ago
3 years ago

People

(Reporter: James Turner, Unassigned)

Tracking

Details

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
LaunchChildMac is used when re-launching the application (eg due to an updated version being installed, or the component registry being rebuilt).  At present it doesn't copy the environment variables of the parent (original) process through to the child, which caused some surprises while testing / developing.

Patch against MacLaunchHelper.m to follow shortly.
(Reporter)

Comment 1

11 years ago
Created attachment 268071 [details] [diff] [review]
Proposed fix, copy the environment from NSProcessInfo

Updated

11 years ago
Attachment #268071 - Flags: review?(joshmoz)

Comment 2

11 years ago
Comment on attachment 268071 [details] [diff] [review]
Proposed fix, copy the environment from NSProcessInfo

looks fine to me but I want mento to review this as well
Attachment #268071 - Flags: review?(mark)
Attachment #268071 - Flags: review?(joshmoz)
Attachment #268071 - Flags: review+

Comment 3

11 years ago
Comment on attachment 268071 [details] [diff] [review]
Proposed fix, copy the environment from NSProcessInfo

Huh.  I thought that the environment was already carried through correctly.  For example, MOZ_LAUNCHED_CHILD, which we set in the parent process during XRE restart, is properly picked up in the child process.  James, what specific behavior are you experiencing/what variables are you finding not being set according to your expectations?

Comment 4

11 years ago
James, do you have any responses to comment 3?
(Reporter)

Comment 5

11 years ago
The specific env var was DYLD_LIBRARY_PATH, which makes me wonder if it's treated specially. However, other changes have made this fix less important, so perhaps it should simple be dropped.

Comment 6

11 years ago
Well, we're getting most of the environment carried through - if the system is purposely preventing a few variables from making it, it's probably got a reason, and I don't want to override that unless it fixes something that we're definitely doing wrong.  Are you saying that DYLD_LIBRARY_PATH is now carried through properly, or that something else changed and you no longer need DYLD_LIBRARY_PATH?

Updated

11 years ago
Attachment #268071 - Flags: review?(mark)
(Reporter)

Comment 7

11 years ago
(Sorry for the delay) - something else changed and we no longer need DYLD_LIBRARY_PATH. Shall I resolve this as WONTFIX? (Not sure if I have permissions for that)

Updated

6 years ago
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
(Assignee)

Updated

3 years ago
Product: Toolkit → Toolkit Graveyard
You need to log in before you can comment on or make changes to this bug.