Community
Participate
Working Groups
See the attachment https://bugs.eclipse.org/bugs/attachment.cgi?id=274951 from https://bugs.eclipse.org/bugs/show_bug.cgi?id=530835 and the comment of Sebastian in https://bugs.eclipse.org/bugs/show_bug.cgi?id=530835#c50 (In reply to Karteek M from comment #28) > We also tested few other cases and found the observations as attached in the > ppt with the name "URI_scheme_behaviour_in_Windows.pptx". > > > The whole activity is with respect to Windows as OS. I have analyzed the problem a bit further, and this is not something that the operation system is causing, but the way the eclipse.exe launcher binary tries to re-use existing instances: - When a file/URL should be opened, it attempts to re-use an existing workbench: https://git.io/fN80b - It does this by attempting to find an existing SWT window with the window name SWT_Window_${name} and sending it a WindowMessage, then simply exiting itself. - The launcher binary deduces this 'name' from the eclispe binary name, e.g. c:\foo\EclipseInstallationA\eclipse.exe -> 'Eclipse': (getDefaultOfficialName(), https://git.io/fN8zJ) - The matching SWT window gets its name from Display.setAppName(name) with name coming from either WorkbenchPlugin.getDefault().getAppName() (in Workbench) or Platform.getProduct() (in E4Application) Implications: - As long as there is only one installation of each eclipse product all should be fine, and the correct window is found and re-used. - If there are multiple installations of the same product, it does not matter which of the product.exe is given in the URL handler registration. There is no way to enforce the re-use of a specific instance / installation (if at least one of them is already running). This scenario is not very unlikley, since a basic "Eclipse" product is often the base installation enriched with different plugins. - Even if only one installation of a product exists, technically, it is possible to still run two instances of the binary with different workspaces. There is also no way to register the URL handler with a specific one of those and ensure that only this instance is re-used. - The problem affects opening URLs in a specific installation / window the same way as opening files, i.e. associcating *.java with a specific eclipse.exe does also not guarantee that the correct instance is re-used, if there exist more than one running installation with the same product name. Possible solutions: - Unique window ID: The name of the SWT window could be SWT_Window_${product}_{id}, with id being unique to the installation and stable. - Finding the unique ID from the launcher binary: A) The created file / URL assocications could enforce the re-use of this specific ID: c:\foo\EclipseA\eclipse.exe -name Eclipse_123456789 --launcher.openfile "%1" -> This is not a very common pattern and would not be created like this if the user simply choses to open *.java with some eclipse.exe B) The ID could somehow be persistend in the configuration and extracted by the launcher (change the way getDefaultOfficialName() works: https://git.io/fN8zJ). - With solution A) an ID could even be unique to a *workspsace* and even support re-using the correct window even with 2 workspaces of the same launcher binary
This looks like a really hard problem to solve. Suppose we really wanted what you spelled out: - With solution A) an ID could even be unique to a *workspsace* and even support re-using the correct window even with 2 workspaces of the same launcher binary The launcher itself would need to specify the -data argument before launching the IDE application if the application is not already launched with that workspace... In any case, the installer has had to "reimplement" many of the behaviors of the IDE for supporting open-document and open-url is similar ways so I'll keep on eye on any future behavior changes that might be implemented via this Bugzilla.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
