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

OSX bundle id collides with base electron app, making basic applescript automations open the Electron starter app. #46762

Closed
Sschumac opened this issue Mar 27, 2018 · 7 comments
Assignees
Labels
bug Issue identified by VS Code Team member as probable bug macos Issues with VS Code on MAC/OS X workbench-os-integration Native OS integration issues

Comments

@Sschumac
Copy link

Sschumac commented Mar 27, 2018

Attempting to automate windows with applescript causes the base electron app on the system to run, making it difficult to make VSCode an active window. VSCode shares a bundle ID with the base electron app "com.github.electron", which causes OSX System Events to be confused with which app to activate.

  • VSCode Version: 1.21.1
  • OS Version: High Sierra 10.13.3

Steps to Reproduce:

  1. Have a project with electron in its node_modules somewhere on your system.
  2. Start VSCode
  3. Run this applescript which gets processes, and checks for windows. The variable appa gets set to the bundle ID "Electron" which confuses OSX.


on getWindows(appa)
	tell application appa
		set idList to null
		set nameList to null
		try
			set idList to the id of every window
		end try
		try
			set nameList to the name of every window
		end try
	end tell
	return idList & nameList
end getWindows

tell application "System Events"
	set openApps to {name, unix id, title} of (processes where background only is false)
end tell

set processList to item 1 of openApps
repeat with i from 1 to length of item 1 of openApps
	set item i of processList to {|name|:item i of processList, title:item i of item 3 of openApps, pid:item i of item 2 of openApps, |windows|:getWindows(item i of processList), id:id of application (item i of processList)}
end repeat
processList

Does this issue occur when all extensions are disabled?: Yes

@Sschumac Sschumac changed the title OSX bundle id collides with base electron app, making basic applescript automations difficult. OSX bundle id collides with base electron app, making basic applescript automations to open Electron starter app. Mar 27, 2018
@Sschumac Sschumac changed the title OSX bundle id collides with base electron app, making basic applescript automations to open Electron starter app. OSX bundle id collides with base electron app, making basic applescript automations open the Electron starter app. Mar 27, 2018
@joaomoreno
Copy link
Member

joaomoreno commented Mar 28, 2018

The app we ship has this in its Info.plist:

    <key>CFBundleIdentifier</key>
    <string>com.microsoft.VSCode</string>

Are you sure about that bundle id?

@joaomoreno joaomoreno reopened this Mar 28, 2018
@joaomoreno joaomoreno added the info-needed Issue requires more information from poster label Mar 28, 2018
@Sschumac
Copy link
Author

Hmm you are correct.
the applescript snippet:

id of application "Visual Studio Code"

returns the correct "com.microsoft.VSCode"

but when getting all running non-background processes with

tell application "System Events"
	set openApps to application (processes where background only is false)
end tell

VSCode is reported as

application process "Electron"

with the id

"com.github.electron"

This is the only electron app on my system that exhibits this behavior.

@Sschumac
Copy link
Author

Sschumac commented Mar 30, 2018

I noticed that other electron apps list the executable file in the info.plist as their app name, while VSCode simply uses "Electron"

@joaomoreno joaomoreno added bug Issue identified by VS Code Team member as probable bug macos Issues with VS Code on MAC/OS X workbench-os-integration Native OS integration issues and removed info-needed Issue requires more information from poster labels Apr 3, 2018
@joaomoreno joaomoreno added this to the April 2018 milestone Apr 3, 2018
@joaomoreno
Copy link
Member

Got it, we can change that.

joaomoreno added a commit that referenced this issue Apr 25, 2018
@joaomoreno
Copy link
Member

Risky changes for endgame. Created branch, needs review next week.

@joaomoreno joaomoreno modified the milestones: April 2018, May 2018 Apr 25, 2018
@joaomoreno joaomoreno modified the milestones: May 2018, June 2018 May 29, 2018
@joaomoreno joaomoreno modified the milestones: June 2018, July 2018 Jun 27, 2018
@joaomoreno
Copy link
Member

Unfortunately I'm going to have to close this as I can't get a successful update flow working with Squirrel after renaming the executable. I do want this fixed, but not at the cost of breaking the updates for every macOS user. It's too late. 😢

@joaomoreno joaomoreno modified the milestones: July 2018, Backlog Jul 18, 2018
@vscodebot vscodebot bot locked and limited conversation to collaborators Sep 1, 2018
@deepak1556 deepak1556 reopened this Nov 11, 2021
@deepak1556 deepak1556 assigned deepak1556 and unassigned joaomoreno Nov 11, 2021
@deepak1556 deepak1556 modified the milestones: February 2022, Backlog Feb 24, 2022
@deepak1556 deepak1556 removed this from the Backlog milestone Dec 12, 2022
@deepak1556
Copy link
Collaborator

Closing as we haven't got more issues with renaming the executable and it is not worth breaking the update flow.

@deepak1556 deepak1556 closed this as not planned Won't fix, can't repro, duplicate, stale Dec 12, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Issue identified by VS Code Team member as probable bug macos Issues with VS Code on MAC/OS X workbench-os-integration Native OS integration issues
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

4 participants