Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updating to electron 8 #4295

Closed
LabhanshAgrawal opened this issue Feb 18, 2020 · 7 comments · Fixed by #4357
Closed

Updating to electron 8 #4295

LabhanshAgrawal opened this issue Feb 18, 2020 · 7 comments · Fixed by #4357

Comments

@LabhanshAgrawal
Copy link
Collaborator

#4283 is failing because we need newer node-abi also for electron-rebuild to work (see this).

Updating to electron 8 introduces some issues though.
One I've been able to identify is with cwd, it's getting set as undefined and thus hyper starts at / when opened or the hyper git folder during dev with yarn run app.
Explanation:
While creating a new session
https://github.com/zeit/hyper/blob/d0ce94ce8ea690012778069db5deb80d624f73c8/app/ui/window.ts#L135-L136
the extraOptions can have these keys splitDirection, cwd, activeUid, isNewGroup normally
Out of these, value of cwd is always undefined as it's being taken from ui state which doesn't have cwd initially and the SESSION_SET_CWD action is not triggered anywhere in the codebase.

This didn't cause us any problems earlier as until now the ipc had been removing the keys with undefined values and we're using the extraOptions here
https://github.com/zeit/hyper/blob/d0ce94ce8ea690012778069db5deb80d624f73c8/app/ui/window.ts#L118-L127
So, cwd was always getting set to workingDirectory

But in electron 8, this behaviour of ipc has changed electron/electron#20214
it now sends the object properly, so now extraOptions has the cwd key with undefined value, which overwrites workingDirectory in Object.assign thus causing the issue.

We can fix this in a number of ways:
Setting the workingDirectory value in the initial ui state
Filtering undefined values before Object.assign
Emitting a SESSION_SET_CWD action before the session creation etc.

This was one issue which was apparent and I was able to dig into, if I find any more, I'll add it here or create separate issues.

@LabhanshAgrawal
Copy link
Collaborator Author

I think setting cwd in initial ui state and filtering undefined values should both be done for this.
@Stanzilla what do you think about it?

@Stanzilla
Copy link
Collaborator

Setting cwd ourselves ensures that the behaviour of every later action is the same as before, so I think that's the safest way as well?

@LabhanshAgrawal
Copy link
Collaborator Author

I agree, I suggested filtering undefined also as if any plugin triggers the session_set_cwd action with undefined then I think workingDirectory should be used, or is that too many fallbacks and might not really happen irl

@Stanzilla
Copy link
Collaborator

Yeah, I don't have a good insight into what plugins do these days but we might just also tell them if they do that to help their debugging

@LabhanshAgrawal
Copy link
Collaborator Author

While trying to put the initial working directory in ui state I am having issues with opening hyper from cli, and the Open Hyper Here menu on Windows.
I think I don't fully understand how opening from cli works
https://github.com/zeit/hyper/blob/d0ce94ce8ea690012778069db5deb80d624f73c8/app/ui/window.ts#L62-L68
Here workingDirectory is set in this order process.argv > cfg.workingDirectory > homeDirectory and this is set only once when the window is opening, so once it is set all the subsequent tabs and splits should also open at the same location.

This is true on Windows, but the behaviour is different on mac (don't have linux to test)
On mac the first session opens at the location set in the cli call but subsequent sessions open at the default location.
One thing to note is that on windows the shell opens directly at specified location, but on mac it opens at default location and then cds to the specified location (which might be the reason for subsequent sessions).

On using the ui state solution, opening from cli is working in macOs but it's not in Windows (both cli and context menu).

This behaviour of cli/context menu seems strange and I'll have to take a deeper look into how it's being done to do the ui state solution, but this will take some time.

For now I think we should filter out the undefined keys from the extraOptions object to have the same behaviour as before (tested fine on mac and windows).

@Stanzilla
Copy link
Collaborator

Maybe @chabou can help here, CLI was his baby

@LabhanshAgrawal
Copy link
Collaborator Author

@Stanzilla I think we should go ahead with

For now I think we should filter out the undefined keys from the extraOptions object to have the same behaviour as before (tested fine on mac and windows).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants