Community
Participate
Working Groups
This is a sub-topic bug for the top level bug 530833. For the overall big picture please see top level bug 530833. Similar issue is described in https://bugs.eclipse.org/bugs/show_bug.cgi?id=351303#c40 We have to provide a mechanism to tell the operating system which URL protocols can be handled by an Eclipse installation so that the operating system knows which application to call when a link with these specific URL protocol is clicked. This for sure is operating system specific. See https://stackoverflow.com/questions/1947209/registering-a-url-protocol-handler-in-a-multiple-platforms 1.) On Windows one has to create some registry entries. 2.) On macOS you have to provide some entries in the applications’s Info.plist file. 3.) On Linux your have to provide a .desktop file. For 1.) https://msdn.microsoft.com/en-us/library/aa767914(v=vs.85).aspx describes what needs to be written to the registry. We have a solution for windows to write the registry entries out of Java code. We can also contribute this to eclipse platform. This implementation uses java.util.prefs.Preferences to write into registry below HKEY_CURRENT_USER. It uses some reflection to be able to call private methods like “openKey” and “closeKey”. This is not so nice but we don’t know any other nicer solutions. We could call the “reg.exe” via Runtime.getRuntime().exec() but is this really nicer? In addition our implementation is running since years (on java 1.6, 1.7 and 1.8) without issues. We may need to check if it still runs on Java 9 and 10. For 2.) https://stackoverflow.com/questions/471581/how-to-map-a-custom-protocol-to-an-application-on-the-mac describes what needs to be written into the Info.plist file. As the Info.plist file basically is xml we could use an xml parser to read the existing info.plist file and add additional CFBundleURLTypes like in <key>CFBundleURLTypes</key> <array> <dict> <key>CFBundleURLName</key> <string>Cliff's handler</string> <key>CFBundleURLSchemes</key> <array> <string>abcdef</string> </array> </dict> </array> They question is if macOS will notice the change in the file automatically or if we need to trigger a refresh after changing that file. Apache commons https://commons.apache.org/proper/commons-configuration/index.html also has support of that. I am not sure if we are allowed to use that library in Eclipse code. For 3.) https://superuser.com/questions/162092/how-can-i-register-a-custom-protocol-with-xdg/309343#309343 gives some insights what needs to be done on Linux. Also see https://bugs.eclipse.org/bugs/show_bug.cgi?id=525305#c23 You have to create a .desktop file and put the file in ~/.local/share/applications or /usr/local/share/applications. I think it should also be feasible to write a parser for the .desktop file. It looks like a simple properties file with name/value pairs. We already should have code in eclipse that can read / write such files. Registering URL protocol handlers in the operation system is an operation that normally is done by the installer of an application. But as you can install additional software into Eclipse later on and such additional software might add additional URL protocol we also need to support of registering / un-registering URL protocol handlers in the OS during runtime of the Eclipse platform. If you provide a complete Eclipse product (maybe with an installer) this registration may be done there but it’s important that is also works in use-cases where users take a “plain” Eclipse installation and add additional features via an update site - as SAP does with the ABAP Development Tools (https://tools.hana.ondemand.com/#abap). We have to think when we would trigger this registration. We first though we could handle this via an p2-advice (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=339526#c1) but this seems not to be feasible because on Windows and Linux you have to write registry / files outside of your application’s directory. So maybe we should do this at runtime of Eclipse. I have two possibilities in mind: a) Automatically at start-up. This has the draw back that this may increase start-up time. An on the other hand a user might have different installations that can handle the same URL protocols but only want’s to register one specific installation and does not want to register the other installations. b) Triggered explicitly by a user action e.g. out of a preferences page. A preference page similar to todays “Startup and Shutdown” page could provide a list of all available URL protocols and the user can tick the URL protocols he want’s to register in the operating system. Apply-ing these settings would then execute the registration in the operating systems. See also https://bugs.eclipse.org/bugs/show_bug.cgi?id=351303#c40 on that Does somebody have other ideas when and how we could trigger this registration? We may also think about the un-installation of plug-ins. At uninstallation time we maybe should un-register URL protocol handlers in the operating system. Any suggestions regarding 1.) 2.) and 3.)?
Created attachment 272600 [details] Screencast showing the issue with not handler registered in OS This screencast shows what's happening when there is not URL protocol handler registered in the operating system using SAP's ABAP Development Tools as example.
Created attachment 272601 [details] Registering Eclipse as URL protocol handler on windows This screencast shows how we currently do the registration of the running Eclipse application as URL protocol handler in SAP's ABAP Development Tools.
Created attachment 272602 [details] Windows Registry after registration of Eclipse as URL protocol handler This screenshot shows how the windows registry looks like after we have registered the running Eclipse application as URL protocol handler for the adt: URL protocol used in SAP's ABAP Development Tools
@Thomas W.: What's your opinion on this? - Is usage of reflection into the JDK in Eclipse Platform for 1.) an issue? - Where (which bundle) should we put this registration stuff into? - For 3.) .desktop files are basically properties files. Do we already have infrastructure for writing / parsing / modifing such files in the platform?
Details for the info.plist file on Mac: XML Property Lists: https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/PropertyLists/AboutPropertyLists/AboutPropertyLists.html#//apple_ref/doc/uid/10000048i-CH3-SW2 http://www.apple.com/DTDs/PropertyList-1.0.dtd The .desktop file is a property file. So it may be sufficient to use java.util.properties to parse and modify the file.
New Gerrit change created: https://git.eclipse.org/r/124880
New Gerrit change created: https://git.eclipse.org/r/125043
I just tested with the sdk-i-build from http://download.eclipse.org/eclipse/downloads/drops4/I20180701-2000/ This includes the new org.eclipse.urischeme plugin. The download of the "Example Plug-ins" of this i-build does not yet include the org.eclipse.ui.examples.uriSchemeHandler. So I created the corresponding JAR locally and dropped it into the plugins-directory. After a restart one now sees the "Fire open url event" command. Triggering this shows that the org.eclipse.urischeme and the org.eclipse.ui.examples.uriSchemeHandler plugin are working fine (because a dialog with the triggered uri appears). I now manually tweaked the Info.plist file of the i-build to include: <key>CFBundleURLTypes</key> <array> <dict> <key>CFBundleURLName</key> <string>The hello protocol</string> <key>CFBundleURLSchemes</key> <array> <string>hello</string> </array> </dict> </array> as last key-value pair (after the CFBundleDisplayName key value pair) in the top-level <dict> element. I now tried to open Eclipse with that Event via the following command line open -a <path to Eclipse.app> hello://from/command/line this failed because the OS does not yet know the hello uri scheme. To trigger a re-reading of the Info.plist I copied the Eclipse.app to another directory. This caused macOS to re-read the Info.plist file. Triggering now via open -a <path to Eclipse.app> hello://from/command/line now correctly opens up eclipse and shows the dialog of the org.eclipse.ui.examples.uriSchemeHandler plugin. To verify if macOS knows the uri scheme one can use the following command line: /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -dump | grep hello When successful something like: CFBundleURLName = "The hello protocol"; hello schemesList: hello name: The hello protocol bindings: hello: appears. After the successfull registration also the command line open hello://from/command/line (without the -a) works fine and opens the correct eclipse.app and shows the expected dialog there. So the question now is how to trigger re-reading the Info.plist file without move-ing it around.
also pasting hello://from/command/line into chrome's or safari's address bar or clicking on a hello://from/command/line linke in an e-amil opens up eclipse correctly.
When multiple applications claim to handle the same uri scheme, macOS seems to launch the first one it finds. So there is no dialog to let the user decide which one to launch.
(In reply to Matthias Becker from comment #8) > So the question now is how to trigger re-reading the Info.plist file without > move-ing it around. /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -r <path to Eclipse.app> registers the app and it's URL scheme /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -u <path to Eclipse.app> unregisters the app So one possibility to automate the update of macOS cache is to first call /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -u <path to Eclipse.app> directly followed by /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -r <path to Eclipse.app> whenever we manipulate the Info.plist file. Just running /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -r <path to Eclipse.app> seems not to be sufficient.
Just encountered the following situation on macOS. A User has two eclipse installations. Installation A cannot handle the hello URI scheme and Installation B can handle the hello URI scheme. Installation A is running and installation B is not running. Now the user clicks the link "hello://from/command/line". This now brings the running installation A to the front instead of starting up installation B. Nothing happens in installation A because there no handler exists. As soon as the user closes installation A macOS correctly starts up installation B when the user clicks a link. The cause seems to be that macOS only checks the name of the running binary. As A and B both have "eclipse" as running binary macOS thinks installation A is installation B. I don't think we have a possibility to change this. Anyway it "only" is a edge case we can live with.
(In reply to Matthias Becker from comment #0) > For 3.) > https://superuser.com/questions/162092/how-can-i-register-a-custom-protocol- > with-xdg/309343#309343 gives some insights what needs to be done on Linux. > Also see https://bugs.eclipse.org/bugs/show_bug.cgi?id=525305#c23 > You have to create a .desktop file and put the file in > ~/.local/share/applications or /usr/local/share/applications. I think it > should also be feasible to write a parser for the .desktop file. It looks > like a simple properties file with name/value pairs. We already should have > code in eclipse that can read / write such files. Successfully tested on Redhat. Added a line MimeType=x-scheme-handler/hello; to eclipse desktop file. changed the "EXEC" line of the desktop file and add %u add the end (for the uri). Placed file in ~/.local/share/applications. Add a line to ~/.local/share/application/mimeapps.list by "xdg-mime default eclipse.desktop x-scheme-handler/hello". Call "xsg-open hello://test". Eclipse opens and shows the popup of the sample plugin. Also with an already open Eclipse this works. Open question is, whether the xdg tool is available on on linux distros?
(In reply to Marcus Höpfner from comment #13) > (In reply to Matthias Becker from comment #0) > > > For 3.) > > https://superuser.com/questions/162092/how-can-i-register-a-custom-protocol- > > with-xdg/309343#309343 gives some insights what needs to be done on Linux. > > Also see https://bugs.eclipse.org/bugs/show_bug.cgi?id=525305#c23 > > You have to create a .desktop file and put the file in > > ~/.local/share/applications or /usr/local/share/applications. I think it > > should also be feasible to write a parser for the .desktop file. It looks > > like a simple properties file with name/value pairs. We already should have > > code in eclipse that can read / write such files. > > Successfully tested on Redhat. > Added a line > MimeType=x-scheme-handler/hello; > to eclipse desktop file. > changed the "EXEC" line of the desktop file and add %u add the end (for the > uri). > Placed file in ~/.local/share/applications. > Add a line to ~/.local/share/application/mimeapps.list by > "xdg-mime default eclipse.desktop x-scheme-handler/hello". > > Call "xsg-open hello://test". Eclipse opens and shows the popup of the > sample plugin. > Also with an already open Eclipse this works. > > Open question is, whether the xdg tool is available on on linux distros? Does this mean we have to call it multiple times when we register multiple schemes? What needs to done when we un-register a scheme?
Created attachment 274886 [details] UI mockup of Preference page for URI Schemes The uploaded mockup has a table which would be part of the preference page. From the table,the user can choose which URI scheme he would like to be handled by the current eclipse instance. What it means is : If a user selects the checkbox for a URI scheme in a specific eclipse instance,the same eclipse instance would open and handle the scheme whenever that URI scheme is triggered from an external source (Eg: browser). The current path for the scheme is mentioned as "Handler:<path>" below the table. How to remove a handler for a scheme?: If a user selects and unselects a checkbox,then the handler for the scheme is removed (mentioned as "Handler:<none>") upon applying.
(In reply to Arunkumar S from comment #15) > Created attachment 274886 [details] > UI mockup of Preference page for URI Schemes > > The uploaded mockup has a table which would be part of the preference page. > From the table,the user can choose which URI scheme he would like to be > handled by the current eclipse instance. > > What it means is : > If a user selects the checkbox for a URI scheme in a specific eclipse > instance,the same eclipse instance would open and handle the scheme whenever > that URI scheme is triggered from an external source (Eg: browser). > The current path for the scheme is mentioned as "Handler:<path>" below the > table. > > How to remove a handler for a scheme?: > If a user selects and unselects a checkbox,then the handler for the scheme > is removed (mentioned as "Handler:<none>") upon applying. Please provide your valuable feedback on the attached mockup.
New Gerrit change created: https://git.eclipse.org/r/125791
https://bugs.eclipse.org/bugs/show_bug.cgi?id=467000 also gives some information about the .desktop file stuff
(In reply to Matthias Becker from comment #18) > https://bugs.eclipse.org/bugs/show_bug.cgi?id=467000 also gives some > information about the .desktop file stuff Sorry, it is: https://bugs.eclipse.org/bugs/show_bug.cgi?id=494735
@Andrey, Leo, Eric and Sravan: Our team at SAP is a windows / mac "shop". We are not very familiar with linux. The git history tells me that you are Linnux Users. Can you help us understand how the mechanism of the ".desktop" files work? For this bug we need to register a distinct eclipse installation at OS-level as capable to handle links with a custom URI scheme. According to freedesktop.org ".desktop" files do this. Eclipse downloads from download.eclipse.org don't come with such files. So I assume that users do create them manually today (so have Eclipse in the application menu). For this bug we only need this file for the URI scheme handling stuff (via the MimeType=x-scheme-handler/hello). See what Marcus found out in https://bugs.eclipse.org/bugs/show_bug.cgi?id=530835#c13 We are unsure where we should search for an existing / create a new .desktop file without messing up the user's system. Is it possible to put a .desktop file into the installation directory of the eclipse installation what contains the "MimeType" key and has the "NoDisplay" key set to true? If yes: Would that interfere with another .desktop file a user has e.g. in ~/.local/share/applications ? It would be great if one of you could help with that topic.
(In reply to Matthias Becker from comment #20) > @Andrey, Leo, Eric and Sravan: > Our team at SAP is a windows / mac "shop". We are not very familiar with > linux. The git history tells me that you are Linnux Users. Can you help us > understand how the mechanism of the ".desktop" files work? > > For this bug we need to register a distinct eclipse installation at OS-level > as capable to handle links with a custom URI scheme. According to > freedesktop.org ".desktop" files do this. Eclipse downloads from > download.eclipse.org don't come with such files. So I assume that users do > create them manually today (so have Eclipse in the application menu). > > For this bug we only need this file for the URI scheme handling stuff (via > the MimeType=x-scheme-handler/hello). See what Marcus found out in > https://bugs.eclipse.org/bugs/show_bug.cgi?id=530835#c13 > > We are unsure where we should search for an existing / create a new .desktop > file without messing up the user's system. > > Is it possible to put a .desktop file into the installation directory of the > eclipse installation what contains the "MimeType" key and has the > "NoDisplay" key set to true? > If yes: Would that interfere with another .desktop file a user has e.g. in > ~/.local/share/applications ? > > It would be great if one of you could help with that topic. I don't know how windows and mac do the file or url handling, but on linux it basically tries to convert the given input into a URL (e.g http..) and if that fails it's a file. So you either get openURL or openFILE signal (exact signal name might be differet, look it up in SWT.java). You can then do what you like with the open* signals. If you want a custom handler, then you need to piggy onto those and figure out your mime. Note, SWT doesn't actually know about eclipse and eclipse ini. It just handles urls/files.
(In reply to Leo Ufimtsev from comment #21) > I don't know how windows and mac do the file or url handling, but on linux > it basically tries to convert the given input into a URL (e.g http..) and if > that fails it's a file. So you either get openURL or openFILE signal (exact > signal name might be differet, look it up in SWT.java). > > You can then do what you like with the open* signals. If you want a custom > handler, then you need to piggy onto those and figure out your mime. Note, > SWT doesn't actually know about eclipse and eclipse ini. It just handles > urls/files. Thanks Leo for the quick response. I already know this. But this is when the SWT already received the URL and then issues the SWT.OpenFile / SWT.OpenUrl event. We already have implemented the handling of this inside eclipse with https://bugs.eclipse.org/bugs/show_bug.cgi?id=530834. But what I am asking is the part before the URL is handed over from the OS / desktop to the binary running. So when the user clickes on a link e.g. in an e-mail or on a web page. The OS has to know which program to start. This is done via the .desktop files. Do you know more details about this part?
(In reply to Matthias Becker from comment #22) > (In reply to Leo Ufimtsev from comment #21) > > I don't know how windows and mac do the file or url handling, but on linux > > it basically tries to convert the given input into a URL (e.g http..) and if > > that fails it's a file. So you either get openURL or openFILE signal (exact > > signal name might be differet, look it up in SWT.java). > > > > You can then do what you like with the open* signals. If you want a custom > > handler, then you need to piggy onto those and figure out your mime. Note, > > SWT doesn't actually know about eclipse and eclipse ini. It just handles > > urls/files. > Thanks Leo for the quick response. > > I already know this. But this is when the SWT already received the URL and > then issues the SWT.OpenFile / SWT.OpenUrl event. We already have > implemented the handling of this inside eclipse with > https://bugs.eclipse.org/bugs/show_bug.cgi?id=530834. > > But what I am asking is the part before the URL is handed over from the OS / > desktop to the binary running. So when the user clickes on a link e.g. in an > e-mail or on a web page. The OS has to know which program to start. This is > done via the .desktop files. > Do you know more details about this part? Are you refering to the Gnome .desktop file? ~For Gnome: (I don't know if KDE/others also use .desktops...) I found this article quite useful: https://developer.gnome.org/integration-guide/stable/desktop-files.html.en Generally googling "Gnome .desktop files" produces lots of useful stuff. I've made a .desktop file to assosiate pdf's with my pdf reader that I installed into a custom location for instance. As per article above, the .desktop file has to be in either of these two folders: " Place this file in the /usr/share/applications directory so that it is accessible by everyone, or in ~/.local/share/applications if you only wish to make it accessible to a single user" Is this what you're looking for?
New Gerrit change created: https://git.eclipse.org/r/125916
We plan to merge https://git.eclipse.org/r/#/c/124880/ and https://git.eclipse.org/r/#/c/125043/ by the end of this week. Would be great of somebody could give a code review. If we hear nothing we assume it's ok. Anyway the submitted code is not (yet) used productively so merging should not be critical.
New Gerrit change created: https://git.eclipse.org/r/125917
(In reply to Matthias Becker from comment #14) > Does this mean we have to call it multiple times when we register multiple > schemes? > > What needs to done when we un-register a scheme? Answering these question and writing some other observations... First of all the desktop file need to be located in ~/.local/share/applications. Otherwise opening a link does not work. Since we don't want to interfere with users .desktop files for the same eclipse we create another one. This is supported by the system. In that file we write the minimal content for a desktop file which is: [Desktop Entry] Exec=/path/to/eclipse/executable/eclipse %u Type=Application NoDisplay=true MimeType=x-scheme-handler/hello; NoDisplay=true means, the file is just used for the MimeType, not for e.g. menu. The question is, how to name this desktop file. There are two requirements regarding the name. 1.) it must not interfere with existing .desktop files 2.) name should be determinable in order to change it the next time the user changes schemes. So our proposal is, take the full path of the eclipse directory, replace '/' with '_' and take this as file name. E.g. /home/myuser/eclipse would be converted to _home_myuser_eclipse.desktop. After we created/changed this file we call xdg-mime. Seems to have an option to pass multiple handlers at once. To answer your question Matthias, it needs to be called only once. Unfortunately xdg-mime has no unregister. But it is sufficient, to remove the schemes from the desktop file.
Created attachment 274951 [details] URI_scheme_behaviour_in_Windows (In reply to Matthias Becker from comment #8) The sdk-i-build works fine for "Hello" links in Windows. Following are steps followed to achieve it: 1) Downloaded eclipse instance for Windows from the following path: http://download.eclipse.org/eclipse/downloads/drops4/I20180701-2000/ 2)Followed the same process as Matthias suggested of dropping the plugin org.eclipse.ui.examples.uriSchemeHandler into the plugins folder of downloaded eclipse instance. 3)After a restart the "Fire open url event" command could be seen. Triggering this shows the dialog which proves that org.eclipse.urischeme and the org.eclipse.ui.examples.uriSchemeHandler plugin are working fine. 4)Wrote the "Hello" URI scheme along with required path to the Windows Registry. 5)Status:Eclipse instance is closed. Opened hello://demo.url in the browser.The browser popup asks to open eclipse and on clicking it, opens the eclipse instance and shows the dialog in example plugin. 6)Status:Eclipse instance is open. Opened hello://demo.url in the browser.The browser popup asks to open eclipse and on clicking it,the already open application comes to the foreground and shows the dialog in example plugin. 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.
Created attachment 274952 [details] Behaviour on macOS The ppt shows how macOS behaves on "edge" cases. ltdr: - macOS chooses the correct Eclipse instance when multiple Eclipse instances are running (order of starting is not important) - macOS chooses the wrong Eclipse instance when only the wrong Eclipse instance is running
(In reply to Matthias Becker from comment #29) The ppt shows how macOS behaves on "edge" cases. tldr: - macOS chooses the correct Eclipse instance when multiple Eclipse instances are running (order of starting is not important) - macOS chooses the wrong Eclipse instance when only the wrong Eclipse instance is running
just for the sake of completeness: linux seems to behave correctly and always uses the registered eclipse
Gerrit change https://git.eclipse.org/r/124880 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=43e63774d38674c465da56131af58c25ffe9f7c1
Gerrit change https://git.eclipse.org/r/125043 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=aa7f1f2788d90e763fe2f69862935445069c02a6
New Gerrit change created: https://git.eclipse.org/r/126013
New Gerrit change created: https://git.eclipse.org/r/126014
Gerrit change https://git.eclipse.org/r/126013 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=565e91ec98d40aa33eb0672a056e677626fee110
Gerrit change https://git.eclipse.org/r/126014 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=9a5172bc911d0c0bf3c38eeaad6f7b829b350e03
(In reply to Matthias Becker from comment #0) > I now manually tweaked the Info.plist file of the i-build to include: How would this work for installations where you don't have write access to the Eclipse.app dir? And doesn't it break application signing?
(In reply to Carsten Reckord from comment #38) > (In reply to Matthias Becker from comment #0) > > I now manually tweaked the Info.plist file of the i-build to include: > > How would this work for installations where you don't have write access to > the Eclipse.app dir? And doesn't it break application signing? Good questions. Regarding the signing. I just tried this by downloading a new Eclipse Photon and verifying it's signature with: spctl --assess --verbose <pathTo>Eclipse.app I got: <pathTo>Eclipse.app: accepted source=Developer ID Then I modified the plist file (by adding a space somewhere. Then I got: <pathTo>Eclipse.app: invalid Info.plist (plist or signature have been modified) So this is bad in general. But https://www.macissues.com/2015/11/06/how-to-verify-app-signatures-in-os-x/ says: "Note that if you have explicitly run your app and confirmed to bypass GateKeeper’s warnings, then it may still run even if not properly signed, so if manual assessment of your app shows it as being rejected, then consider investigating it." When I download the eclipse dmg from eclipse.org I have to accept a warning anyway when running it first because it's "from the internet" and not from the app store. So because of this I never got a warning dialog that the signature is broken. So can wie live with that? Regarding re-only: I think in such a case it's simply not possible. But isn't the typical eclipse installation located in the user's Applications directory or somewhere in the user's home?
(In reply to Matthias Becker from comment #39) > (In reply to Carsten Reckord from comment #38) > > (In reply to Matthias Becker from comment #0) > > > I now manually tweaked the Info.plist file of the i-build to include: > > > > How would this work for installations where you don't have write access to > > the Eclipse.app dir? And doesn't it break application signing? > > Good questions. > Regarding the signing. I just tried this by downloading a new Eclipse Photon > and > verifying it's signature with: > spctl --assess --verbose <pathTo>Eclipse.app > I got: > <pathTo>Eclipse.app: accepted > source=Developer ID > > Then I modified the plist file (by adding a space somewhere. Then I got: > <pathTo>Eclipse.app: invalid Info.plist (plist or signature have been > modified) > > So this is bad in general. But > https://www.macissues.com/2015/11/06/how-to-verify-app-signatures-in-os-x/ > says: > > "Note that if you have explicitly run your app and confirmed to bypass > GateKeeper’s warnings, then it may still run even if not properly signed, so > if manual assessment of your app shows it as being rejected, then consider > investigating it." > > When I download the eclipse dmg from eclipse.org I have to accept a warning > anyway when running it first because it's "from the internet" and not from > the app store. So because of this I never got a warning dialog that the > signature is broken. So can wie live with that? > > Regarding re-only: I think in such a case it's simply not possible. But > isn't the typical eclipse installation located in the user's Applications > directory or somewhere in the user's home? Regarding the signature stuff. Can we change the signing of the dmgs / app bundle eclipse foundation creates to exclude the Info.plist file from the signature?
Adding Mikael Barbero because he may be familiar with the code signing stuff for macOS discussed in comment 38 and later.
(In reply to Matthias Becker from comment #40) > Regarding the signature stuff. Can we change the signing of the dmgs / app > bundle eclipse foundation creates to exclude the Info.plist file from the > signature? AFAICT, no, it's part of the files which need to be signed. It means that any URI scheme needs to be registered when the app bundle is build and cannot be done dynamically.
(In reply to Mikaël Barbero from comment #42) > (In reply to Matthias Becker from comment #40) > > Regarding the signature stuff. Can we change the signing of the dmgs / app > > bundle eclipse foundation creates to exclude the Info.plist file from the > > signature? > > AFAICT, no, it's part of the files which need to be signed. It means that > any URI scheme needs to be registered when the app bundle is build and > cannot be done dynamically. This kills this feature on macOS. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=530833. The whole story is about doing this at runtime because e.g. a user installed a plugin e.g. from eclipse marketplace that has the capability of handling a given uri scheme. An Eclipse Installation can be seen as a (more or less) empty framework where a user later on adds additional functionality. This makes it different to other macOS apps.
(In reply to Matthias Becker from comment #43) > (In reply to Mikaël Barbero from comment #42) > > (In reply to Matthias Becker from comment #40) > > > Regarding the signature stuff. Can we change the signing of the dmgs / app > > > bundle eclipse foundation creates to exclude the Info.plist file from the > > > signature? > > > > AFAICT, no, it's part of the files which need to be signed. It means that > > any URI scheme needs to be registered when the app bundle is build and > > cannot be done dynamically. > > This kills this feature on macOS. See > https://bugs.eclipse.org/bugs/show_bug.cgi?id=530833. The whole story is > about doing this at runtime because e.g. a user installed a plugin e.g. from > eclipse marketplace that has the capability of handling a given uri scheme. > An Eclipse Installation can be seen as a (more or less) empty framework > where a user later on adds additional functionality. This makes it different > to other macOS apps. I just had a look how Visual Studio Code does it. They come with one URI scheme ("vscode") in the Info.plist file: <key>CFBundleURLTypes</key> <array> <dict> <key>CFBundleTypeRole</key> <string>Viewer</string> <key>CFBundleURLName</key> <string>Visual Studio Code</string> <key>CFBundleURLSchemes</key> <array> <string>vscode</string> </array> </dict> </array> A link for installing extensions is then e.g. vscode:extension/vscode-snippet.Snippet Does vscode use this uri scheme also for other stuff other then installing extensions?
(In reply to Matthias Becker from comment #43) > This kills this feature on macOS. I understand this, unfortunately macOS doesn't seem to want apps to do that.
Actually, I chatted with Chris yesterday about the MPC support in bug 536589 and about integrating it on the Marketplace website once everything is in place. And we both agreed that it would probably be a good idea to avoid a total proliferation of URI schemes from any interested bundle. Maybe a lot of usecases could be handled by having a predefined "eclipse" scheme registered in the platform and shipped with the application, and that only delegates to plugin-specific handlers based on the first URI segment. I realize that this won't cover all use-cases, esp. where plugins want to add support for pre-existing schemes out there. But it would cover all directly "Eclipse-related" usage in a clean way.
Also, is there maybe a chance to do directly do whatever lsregister does internally on Mac to register schemes dynamically, without entries in the info.plist?
I haven't the first clue about OS X internals or native OS X development, but maybe having a look at what the apps mentioned here do to register schemes dynamically: https://stackoverflow.com/questions/10597144/how-to-register-an-application-to-a-uri-scheme-in-mac-os-x
Eh, there's a "might help" missing in my previous comment. Also, more: https://superuser.com/questions/548119/how-do-i-configure-custom-url-handlers-on-os-x
(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.
(In reply to Sebastian Ratz from comment #50) > (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. I created a separate bug for this. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=537324
(In reply to Carsten Reckord from comment #38) > How would this work for installations where you don't have write access to > the Eclipse.app dir? And doesn't it break application signing? Modifying does break the signature but this does not have practical relevance. I tell you why: When you download a fresh eclipse (as dmg) from eclipse.org and move the app bundle to a folder on your disk the signature of that app bundle is intact. You see this via: codesign -v --verbose=4 /path/to/Eclipse.app/ /path/to/Eclipse.app/: valid on disk /path/to/Eclipse.app/: satisfies its Designated Requirement When you now execute that app gatekeeper ask you: " “Eclipse.app” is an application downloaded from the Internet. Are you sure you want to open it?" You have to click Open here. Now Eclipse asks the user for the Workspace. In my tests I simply clicked "Cancel" here to stop Eclipse right away. When you now check the signature you now see that the signature is already broken: codesign -v --verbose=4 /path/to/Eclipse.app/ /path/to/Eclipse.app/: a sealed resource is missing or invalid This is due to the fact that eclipse writes a lot of files e.g. in the /Eclipse/configuration sub directory When you now start this Eclipse again you don't get any warning about the broken signature because when you first started you pressed "Open" in the Gatekeeper dialog. TLDR: Eclipse already today breaks the signature and has not issues with it. When you modify an file in the Eclipse app bundle before you first start it you also break the signature: codesign -v --verbose=4 /path/to/Eclipse.app/ /path/to/Eclipse.app/: invalid Info.plist (plist or signature have been modified) In architecture: x86_64 and when you start it you get a Gatekeeper dialog saying: “Eclipse.app” is damaged and can’t be opened. You should move it to the Trash. This is really bad. But in our use-case we modify the plist file at runtime of Eclipse and as Eclipse is running the user already told Gatekeeper to open the Eclipse.app that was downloaded from the internet. So this Gatekeeper dialog does not appear. Also installing updates into Eclipse modifies the app bundle (as new jars are added). So I would say we can live with that "limitation" as we don't make it worse then it is already today. So Gatekeeper is only a "one shot" mechanism to protected against apps that got tampered when you / before you download it. Once you started an app the first time macOS / Gatekeeper does trust this app. Carsten and Mikaël: Do you agree?
New Gerrit change created: https://git.eclipse.org/r/126594
https://git.eclipse.org/r/#/c/125917/ is ready for review. Does somebody have to time to give feedback, Carsten maybe you?
(In reply to Carsten Reckord from comment #46) > Actually, I chatted with Chris yesterday about the MPC support in bug 536589 > and about integrating it on the Marketplace website once everything is in > place. And we both agreed that it would probably be a good idea to avoid a > total proliferation of URI schemes from any interested bundle. Carsten: Any news from your side regarding that topic?
interessting for the registrion on mac: https://developer.apple.com/library/archive/documentation/Carbon/Conceptual/LaunchServicesConcepts/LSCConcepts/LSCConcepts.html#//apple_ref/doc/uid/TP30000999-CH202-TP9 even I don't know if this all is still valid for current macOS versions
If nobody disagrees we plan to merge the three changes https://git.eclipse.org/r/#/c/125917/ https://git.eclipse.org/r/#/c/125791/ https://git.eclipse.org/r/#/c/126594/ next week. Feedback is welcome as always. Most interesting parts are the first two changes. - The first one implements the registration of eclipse as handler for uri schemes on linux an mac. There we do some "fancy" calls to the operating system - The second one implements the registration of eclipse as handler for uri schemes on windows. There we write into windows registry via java reflection. This code is running since years in your commercial Product "ABAP Development Tools" - so this should be quite stable. The last change is the preference page that makes als this functional.
I've only seen the Windows related change right now, so I'm sorry for a rather late comment. Why does that use reflection? I found JNA to be simple to use, it is well tested, and it is available under Apache license: https://github.com/java-native-access/jna. Wouldn't it make sense to use that existing library instead of re-implementing registry access?
(In reply to Michael Keppler from comment #58) > I've only seen the Windows related change right now, so I'm sorry for a > rather late comment. Why does that use reflection? I found JNA to be simple > to use, it is well tested, and it is available under Apache license: > https://github.com/java-native-access/jna. Wouldn't it make sense to use > that existing library instead of re-implementing registry access? Why? Because that's the implementation we have at hand and which is proven since years. And to be honest when you google / SO araound how to write into that branch of windows registry you only find two options a) reflection or b) calling regedit So I have to questions regarding https://github.com/java-native-access/jna - Does it provide the same access to windows registry? - Can we / are we allowed to (licence vise) use it in eclipse platform?
Gerrit change https://git.eclipse.org/r/125917 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=39d9dfea3bb8bff99f0dc8ad7c7451d2aa71391d
Gerrit change https://git.eclipse.org/r/125791 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=94914f2852f0c32e60361648ec82da153b8d70ae
Gerrit change https://git.eclipse.org/r/126594 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=7c7ba4e99e6fa2c16dd90a554d8a381bde616e6e
(In reply to Matthias Becker from comment #57) > If nobody disagrees we plan to merge the three changes > > https://git.eclipse.org/r/#/c/125917/ > https://git.eclipse.org/r/#/c/125791/ > https://git.eclipse.org/r/#/c/126594/ > > next week. Feedback is welcome as always. > > Most interesting parts are the first two changes. > - The first one implements the registration of eclipse as handler for uri > schemes on > linux an mac. There we do some "fancy" calls to the operating system > - The second one implements the registration of eclipse as handler for uri > schemes on > windows. There we write into windows registry via java reflection. This > code is > running since years in your commercial Product "ABAP Development Tools" - > so this > should be quite stable. > > The last change is the preference page that makes als this functional. I now merged all the changes. We will continue testing with i-builds. Help in testing especially on the different linux distros eclipse does support is *very* welcome.
Thank you Marucs, Arun and Karteek for you help.
New Gerrit change created: https://git.eclipse.org/r/131108
Gerrit change https://git.eclipse.org/r/131108 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=0b9c7e9204d6fa4f44c24a138f7e7d32c6807dfc
New Gerrit change created: https://git.eclipse.org/r/131114
The following test files in org.eclipse.tests.urischeme are missing license headers: UriSchemeHandlerSpy.java RegistryWriterMock.java TestUnitLsregisterParser.java WinRegistryMock.java org.eclipse.urischeme files: IUriSchemeExtensionReader.java UriSchemeExtensionReader.java IWinRegistry.java Please fix ASAP.
New Gerrit change created: https://git.eclipse.org/r/131121
(In reply to Alexander Kurtakov from comment #68) > The following test files in org.eclipse.tests.urischeme are missing license > headers: > UriSchemeHandlerSpy.java > RegistryWriterMock.java > TestUnitLsregisterParser.java > WinRegistryMock.java > > org.eclipse.urischeme files: > IUriSchemeExtensionReader.java > UriSchemeExtensionReader.java > IWinRegistry.java > > Please fix ASAP. Done. See my gerrit. I have added you as reviewer. Thank you for the hint. Why don't we check this in the gerrit build?
(In reply to Matthias Becker from comment #70) > (In reply to Alexander Kurtakov from comment #68) > > The following test files in org.eclipse.tests.urischeme are missing license > > headers: > > UriSchemeHandlerSpy.java > > RegistryWriterMock.java > > TestUnitLsregisterParser.java > > WinRegistryMock.java > > > > org.eclipse.urischeme files: > > IUriSchemeExtensionReader.java > > UriSchemeExtensionReader.java > > IWinRegistry.java > > > > Please fix ASAP. > > Done. See my gerrit. I have added you as reviewer. Thank you for the hint. > Why don't we check this in the gerrit build? No one found the time to setup some of the maven plugins to do this check.
Gerrit change https://git.eclipse.org/r/131121 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=97179503d77daa1dd2f848b7f660e887e6fd3da9
New Gerrit change created: https://git.eclipse.org/r/131187
Gerrit change https://git.eclipse.org/r/131187 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=21b360bc7a65261d0f0008532f9c6b3ad8e60076
Could someone kindly review https://git.eclipse.org/r/#/c/131114/. If +2 please merge it. Thanks
New Gerrit change created: https://git.eclipse.org/r/131741
New Gerrit change created: https://git.eclipse.org/r/131742
@Marcus: can you please share on this bug a screenshot of how the page look like before/after your patch? You introduced a checkbox viewer and would like other to be able to have a look at the new page and mention whether the page is still easy enough to grok with the new UI.
@Mickael: has been a Table with a checkbox column before. Page looks similar. Before the Table was created with the corresponding bit. I just changed from TableViewer to CheckboxTableViewer to use the CheckStateListener. ... in order to have easier checkbox-clicked-code.
Gerrit change https://git.eclipse.org/r/131114 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=0b889de6780bae7c7fc68b841d7d4b793cde0c8c
Gerrit change https://git.eclipse.org/r/131742 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=a83d5a5b08fe02c2cd4b2eef0d27c860699c3f02
Gerrit change https://git.eclipse.org/r/131741 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=c4c883ab2c245549658d9f58786704549e1c8db7
Implementation is finished. We did a lot of manual testing. This is what we tested: Testcases TWO ECLIPSE INSTALLATIONS 1) Setup: Two Eclipses. First handles the hello scheme. (tested on MacOS + Red Hat + Win) Open preferences page of second Eclipse. Observation: Hello scheme is not checked. Handler (other Eclipse) is correct. Check scheme Observation: Warning is shown, that setting is not possible. Scheme is unchecked automatically. --> OK 2) Setup: Two Eclipses. First handles the hello scheme. (tested on MacOS + Red Hat + Win) Open preferences page of first Eclipse. Observation: Hello scheme is checked. Handler (this Eclipse) is correct. Uncheck scheme Observation: Scheme is unchecked. Handler: no application Check scheme Observation: Hello scheme is checked. Handler (this Eclipse) is correct. Uncheck scheme Observation: Scheme is unchecked. Handler: no application Apply and Close Reopen preference page Observation: Scheme is unchecked. Handler: no application Open preference page in second eclipse Observation: Scheme is unchecked. Handler: no application --> OK 3) Setup: Two Eclipses. None handles the hello scheme. (tested on MacOS + Red Hat + Win) Open preferences page of first Eclipse. Observation: Scheme is unchecked. Handler: Check scheme Observation: Hello scheme is checked. Handler (this Eclipse) is correct. Uncheck scheme Observation: Scheme is unchecked. Handler: Check scheme Observation: Hello scheme is checked. Handler (this Eclipse) is correct. Apply and Close Reopen page Observation: Hello scheme is checked. Handler (this Eclipse) is correct. Open page in second eclipse Observation: Hello scheme is unchecked. Handler other application (path/to/first/eclipse) --> OK 4) Setup: Two Eclipses. None handles the hello scheme. (tested on MacOS + Red Hat + Win) Open preferences page of second Eclipse. Observation: Scheme is unchecked. Handler: Check scheme Observation: Hello scheme is checked. Handler (this Eclipse) is correct. Uncheck scheme Observation: Scheme is unchecked. Handler: Check scheme Observation: Hello scheme is checked. Handler (this Eclipse) is correct. Apply and Close Reopen page Observation Mac: Hello scheme is checked. Handler (this Eclipse) is correct. Observation Win: Hello scheme is checked. Handler (this Eclipse) is correct. Observation Linux (path to second eclipse is /....../eclipse (copy)/eclipse Warning popup is shown that another eclipse (/....../eclipse (copy)/eclipse) is handling this scheme. Has something to do with the escaped and none escaped name I guess). Expected: checked scheme. Handler: this application (path) --> Fixed OK ONE ECLIPSE 5) Setup: One Eclipse which handles hello scheme (tested on Red Hat + MacOS (High Sierra / Mojave) + Win) Open preference page Observation: Scheme checked. Handler is correct (this Eclipse). Uncheck scheme Observation: Scheme unchecked. Handler: "Other Eclipse (path/to/this/eclipse)" Expected: Handler: no application Remark: After retest this works! --> OK 6) Setup: One Eclipse which handles hello scheme (Red Hat + MacOS (High Sierra / Mojave) + Win) Open preference page Observation: Scheme checked. Handler is correct (this Eclipse). Uncheck scheme Apply Restart Eclipse Open Preference Page Observation: hello scheme still checked Expected: hello scheme unchecked. Handler: no application remark: after retest this works --> OK 7) Setup: (Mac) One Eclipse where the plist file is read-only. Open preference page and change the state of one checkbox. Press apply. The checkbox is changed. If you re-open the page the checkbox again has the old state. Error log contains entry: "Error while writing Scheme information to Operating System " We should show an error dialog. Maybe we should throw dedicated exceptions on the low levels (writing plist file fails, execution of lsregister fails, ....) We might have the same issue on linux. This is fixed. We now get an error dialog saying: "Error while writing Scheme information to Operating System " --> OK 8) Setup: One Eclipse with space in the folder/app name. Hello scheme not handled (tested on Mac + Win + Red Hat) Open the preference page check the hello scheme Apply and close reopen the pref page Observation Mac: scheme is checked, handler: this application (path). Opening hello://test starts Eclipse correctly Observation Red Hat: scheme is not checked, handler: other application (path/to/eclipse (copy)/eclipse Whether link click is opening eclipse cannot be tested since libre office is not working on red hat. --> xdg-open could be used here. See: https://linux.die.net/man/1/xdg-open --> Fixed OK UX 9) Setup: One Eclipse which handles hello scheme (seen on Red Hat) Open preference page Observation: Scheme checked. Handler is correct (this Eclipse). Uncheck scheme Restore Defaults Observation: nothing happens Expected: all Schemes unchecked (for this installation) 10) Setup: Eclipse with a long path. This Eclipse handles the hello scheme (seen on Red Hat) Open the preference page select the line with the hello scheme Observation: handler path is very long and cut. It is not possible to see the whole part (e.g. mark with mouse) except from enlarging the window. Decision: try a Text Control with read only and no border. --> Fixed OK 11) Open preference page Table header (Scheme Name) is cut. Porposed Solution: Link Handlers can handle links with a given scheme. This page allows you to enable and disable link handlers in this application. Table Headers: Scheme | Description --> Fixed OK 12) Setup: Two Eclipses, first handles the hello scheme and many other schemes. Open preference page in second eclipse. All schemes are unchecked which is correct. But without selecting the lines one cannot see, that the scheme is handled. Do we need an indicator per line, that this scheme is handled? Should we then again discuss the disabling of checkbox of handled schemes. Since we have the indicator then that the scheme is handled. This is sufficient for the user and the warning popup is not needed anymore. Decision: last column ("Handler") which has the values (No application, This application, Other application) --> Fixed OK
(In reply to Matthias Becker from comment #83) > Implementation is finished. Cool. Does it require an update of the N&N and/or documentation?
(In reply to Mickael Istria from comment #84) > (In reply to Matthias Becker from comment #83) > > Implementation is finished. > > Cool. > Does it require an update of the N&N and/or documentation? I am working on it.
