This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | [65cat] "cannot execute /usr/bin/firefox" when "run main project" is selected to run a web app from IDE | ||
---|---|---|---|
Product: | platform | Reporter: | mhagberg <mhagberg> |
Component: | Launchers&CLI | Assignee: | Jaroslav Tulach <jtulach> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | abadea, anebuzelsky, av-nb, jglick, mpetras, phejl, pjiricka, vvg |
Priority: | P3 | ||
Version: | 5.x | ||
Hardware: | PC | ||
OS: | Linux | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
mhagberg
2006-05-26 19:31:43 UTC
Wanted to confirm this issue with NB 5.0 and SUSE Linux 10.0 and report some additional details: 1) This issue didn't exist with Firefox 1.0.6 which behaved as expected 2) On 16-Aug-2006 SUSE pushed an online update to SUSE versions 9.2 through 10.1 which upgraded those systems to Firefox 1.5.0.6 so I believe this issue will now effect more developers. 3) The default NB run string <</usr/bin/firefox -remote "openURL({URL})">> has been deprecated since at least Firefox version 1.5.0.1 see: http://www.mozilla.com/firefox/releases/1.5.0.1.html 4) The replacement run string suggested by Mozilla is <<firefox -new-window /url/>>. It produces exactly the result described by mhagberg when the browser is closed. 5) If an instance of Firefox is already running when you run your project things behave correctly with each of these run strings: /usr/bin/firefox -remote "openURL({URL})" /usr/bin/firefox {URL} /usr/bin/firefox -new-window {URL} /usr/bin/firefox -new-tab {URL} 6) A similar issue existed with NB3.4 and was resolved in NB3.6. See: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4792602 confirmed and reproducible, we will consider priority upgrade to P2 Unfortunately there seem to be no working way of passing URL to a running Firefox on OS X (see issue 82040) Reported for 6.0M10 at http://www.netbeans.org/servlets/BrowseList?list=nbusers&by=thread&from=798642 So does this happen only with Firefox 1.5.x, or does this also happen to anyone with Firefox 2.0.x? Thanks. Works for me at least with FF 2.0, but I'm running Ubuntu not SUSE. Works fine for me too on Debian with Firefox 2.0 (downloaded from mozilla.org, not installed from the distro packages). When the browser is already running a new window is opened. If is is not running, then it is started. Reporter: can you still experience the problem with Firefox 2.0? Also: it's nice that they deprecated -remote, but I don't think -new-window and -new-tab are what we want. We want to respect the user preference whether to open new links in a new window and new tab. Why not to use the command "/usr/bin/firefox {URL}"? It should work in a way the user expects (opening the window or tab). However my opinion is not to fix it this way for 6.0 - could break ext browser on any platform. Ok, setting target milestone to 'future'. Looks like I was first follow-up to the original reporter so let me contribute this, since things ARE different with Firefox 2.0.x series browsers. This report is still based on NB 5.0 running on Suse Linux 10.0 -- the only thing changed is the version of Firefox (1.5 -> 2.0.x). With the run string '/usr/bin/firefox -remote "openURL({URL})"' Firefox 2.0.x opens, runs correctly, and does not display an error message when the browser is closed. However, if you run a web application but don't shut down the browser and instead run your web application again then you immediately get the message "Can not execute /usr/bin/firefox. Check that a valid external browser property is set..." With the run string '/usr/bin/firefox -new-tab {URL}"' Firefox correctly opens new tabs each time you start your web application, but then gives you the "Can not execute /usr/bin/firefox.. " message when you shut down the browser. Finally, if you start Firefox 2.0.x BEFORE before you run your web application from the IDE and you're using the run string 'usr/bin/firefox -new-tab {URL}' everything works exactly as expected. Each time you run your application a new tab is opened and there is no error message when you close the browser. I can also confirm the experience reported by emononen that FF2.0 on Ubuntu does not have the strange behavior it exhibits on Suse 10.0. With Ubuntu 7.04, NB 5.5.1, Firefox 2.0 and the run string '/usr/bin/mozilla-firefox -remote "openURL({URL})" everything behaves as expected. The same poblem here with openSUSE 10.3 and NetBeans IDE 6.0 The same problem here with openSUSE 10.3 and NetBeans IDE 6.0 Here's what I found out, running Netbeans 6.1, Firefox 3.0 beta on Ubuntu Linux 8.04: If firefox is NOT running, then it is loaded and displays the page correctly. If Firefox is already running, it fails with this message. By replacing the parameter string for the firefox browser with just {URL} it works. *** Issue 122784 has been marked as a duplicate of this issue. *** *** Issue 114706 has been marked as a duplicate of this issue. *** *** Issue 139077 has been marked as a duplicate of this issue. *** Also reported at: http://blogs.sun.com/NetBeansSupport/entry/firefox_and_netbeans ...This goes on and on. I have been fixing this every time I upgrade for I don't know how long now. Yes, I can use the /usr/bin/firefox -remote "URL(...)" from the command line, and I can also use /usr/bin/firefox -new-tab ... from the command line, but only the latter works as an execution argument for firefox within NB. The issue comes up time and again on the mailing list. Maybe the -new-window version should be made the default.... - There does seem to be an issue with the firefox command used by the ide. Perhaps '-remote' itself should be quoted. Or perhaps different versions of firefox (on different OSs) handle command-line arguments differently. - The current message merely says 'Cannot execute /usr/bin/firefox check external browser configuration'. At the least, the message box could display the entire command that the ide is trying to execute (something like " '/usr/bin/firefox -remote <URL>' could not be executed") which might give some clue to the user. Additionally the message box could say that it some cases '-remote' is known to fail and that simply '<firefox-command> {URL}' might work. I am removing the 'INCOMPLETE" keyword which seems to have been added in 11/2007 but further discussions in this thread seems to confirm the issue; please add it back it i removed it incorrectly. Why not just require Java SE 6 for running the NetBeans IDE and use the new java.awt.Desktop class to open a URI in a browser? http://java.sun.com/javase/6/docs/api/java/awt/Desktop.html#browse(java.net.URI) -Puce IMO use JDK 6 just for it is not a good idea. I think what is necessary is had several Firefox version listed on option, with the correct parameters for each version. > IMO use JDK 6 just for it is not a good idea.
Why not? Is this not exactly one of the intentions of the new Desktop class in JDK 6? Just delegate it to the platform
with the benefit that it automatically picks the browser the user has registered as default in his/ her system! Unless I
missed something I think that this is _exactly_ the way to go!
-Puce
*** Issue 124942 has been marked as a duplicate of this issue. *** *** Issue 82040 has been marked as a duplicate of this issue. *** *** Issue 141680 has been marked as a duplicate of this issue. *** This problem is clearly reproducible with NB 6.1 and Fedora 9 and 10. See https://bugzilla.redhat.com/show_bug.cgi?id=467546 Probably, adding some lines at the top of the launch script would resolve this issue, e.g. at the line 40. See original text of the launch script here: http://hg.netbeans.org/release61/file/4f2075f06884/ide/launcher/unix/netbeans ------ # The Startup Notification Protocol Specification established by the freedesktop.org # recommends to unset the DESKTOP_STARTUP_ID environment variable to avoid # possible reuse by some process started later by this process, e.g. when a browser # will be started after clicking on a hyperlink in the NetBeans. if [ ! -z $DESKTOP_STARTUP_ID ] ; then # Save a value for later using in the NB_DESKTOP_STARTUP_ID NB_DESKTOP_STARTUP_ID=$DESKTOP_STARTUP_ID; export NB_DESKTOP_STARTUP_ID unset DESKTOP_STARTUP_ID fi ------ Additional details you can find here: https://bugzilla.redhat.com/show_bug.cgi?id=467546#c3 The patch file that includes this fix here: http://cvs.fedoraproject.org/viewvc/rpms/netbeans/devel/netbeans-6.1-50-ide-launcher.patch?view=markup At least after that the NetBeans correctly opens URLs in the Firefox browser on the Fedora platform in the following situations: * NetBeans is started from the command line, Firefox is not started. * NetBeans is started from the command line, Firefox is already started. * NetBeans is started from GNOME, Firefox is not started. * NetBeans is started from GNOME, Firefox is already started. * NetBeans is started from the command line provided by an X terminal that is run on Windows, Firefox is not started. Passing to launcher to consider the suggestion about DESKTOP_STARTUP_ID. Adding the following lines (as suggested by vvg): ------ # The Startup Notification Protocol Specification established by the freedesktop.org # recommends to unset the DESKTOP_STARTUP_ID environment variable to avoid # possible reuse by some process started later by this process, e.g. when a browser # will be started after clicking on a hyperlink in the NetBeans. if [ ! -z $DESKTOP_STARTUP_ID ] ; then # Save a value for later using in the NB_DESKTOP_STARTUP_ID NB_DESKTOP_STARTUP_ID=$DESKTOP_STARTUP_ID; export NB_DESKTOP_STARTUP_ID unset DESKTOP_STARTUP_ID fi ------ to the netbeans launch script (/usr/local/netbeans-6.5.1/bin/netbeans) fixed the issue for me with Firefox (aka Iceweasel) 3.0.6 on Debian Lenny x86_64. If Firefox isn't running, the web-app launches in a new window; if Firefox is running, the web-app opens a new tab. Should not be assigned to issues@ide, that is not an owner. Jesse, the proposed change is in the 'netbeans' script, that's why evaluation from IDE team was required. Moving to Platform/Launchers & CLI, please evaluate or reassign as appropriate. Still valid? The issue is still valid. Reasons to fix this bug: 1. The NetBeans IDE itself and all other GUI applications based on the NetBeans Platform should meet with the Startup Notification Protocol Specification established by the freedesktop.org. 2. The NetBeans Platform should not have segmentation of the behavior on various Linux platforms, and the behavior must not depend on a way of its distribution. So we should fix bug totally in the hg repository and rely on this in all distributions rather than continue fixing it in each release for particular Linux distributions only. I guess, to provide both #1 and #2 the proposed code should be placed in the script <nb_dir>\platform\lib\nbexec (not in <nbdir>\bin\netbeans !). Fine, I don't understand much the magical properties. But if you have patch I can apply it. Or, feel free to apply it yourself. Fixed in the main trunk http://hg.netbeans.org/main/rev/b8caa9ec7725 Magic of the environment variable DESKTOP_STARTUP_ID is described in the section "Communicating from a launcher process to a launchee process" of the very laconic specification http://standards.freedesktop.org/startup-notification-spec/startup-notification-latest.txt Unsetting this variable in the launchee (i.e. in a NetBeans process) is very important if the launchee is started in an X Window System via a desktop entry that sets the StartupNotify property to true. FYI * StartupNotify=true is a requirement for each desktop entry of the GUI applications on Fedora since version 13. http://cvs.fedoraproject.org/viewvc/rpms/netbeans/devel/netbeans-ide.desktop-template?view=markup * GNOME itself uses this magic http://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkdisplay-x11.c#n1015 Thanks, I am glad I don't need to spend time reading and understanding the spec. Really the patch is not ideal since it is simply disabling the startup notification feature, rather than using it correctly. But I suspect that using it correctly would require JNI/JNA: 1. Do not do anything in the launcher. 2. When the NB main window is shown, look for DESKTOP_LAUNCH_ID using e.g. System.getenv; if unset, skip remaining steps. 3. Use native code to remove this env var from the current process (e.g. g_unsetenv), so that it will not be inherited by future subprocesses. 4. Use native code to notify the desktop that NB has started up (XChangeProperty). This would be one aspect of fixing window focus behavior for NB to match that of native GNOME apps; see bug #182124 for more. (In reply to comment #35) > Really the patch is not ideal since it is simply disabling the startup > notification feature, rather than using it correctly. * My intention was to fix this bug only, but not completely implement the startup notification protocol for the Swing applications. * Current implementation is correct and it meets with the specification: "As a general convention, any key-value pairs in startup notification messages that aren't understood by a given client should be ignored by that client." So the NetBeans provides the general convention against all key-value pairs. * Current implementation fixes this bug, but not change behavior of the NetBeans in other areas. > But I suspect that using it correctly would require JNI/JNA: > > 1. Do not do anything in the launcher. * Current implementation of the launcher script lets to use the NB_DESKTOP_STARTUP_ID in the later steps (if any) instead of the DESKTOP_STARTUP_ID, so there are no any impacts on future development and fixing other bugs. * Finally, please note, such solution doesn't involve any extra components that may/should have dependencies on the native level (platform/architecture/installed components etc.). (In reply to comment #35) > Really the patch is not ideal since it is simply disabling the startup > notification feature, rather than using it correctly. But I suspect that using > it correctly would require JNI/JNA: I guess that fixing this correctly requires some work on JDK side (possibly in cooperation with -splash). The JDK (when splash is on), shall indicate properly that the start is in progress. As soon as first UI element is shown, it shall use the X protocols and tell the desktop that the start is over. CCing Tonda, he knows how to request things from JDK team. In case we decide to cooperate with JDK on proper fix for start indication, let's start new bug to track that progress. (In reply to comment #37) > The JDK (when splash is on), shall indicate properly > that the start is in progress. I _think_ the notification is intended for when the application fully starts, not for when a splash screen is opened. But the spec does not say and it is hard to find an example. > As soon as first UI element is shown I.e. the first java.awt.Window is made visible. > it shall use the X protocols and tell the desktop that the start is over. Yes, this would work well enough. The application does not then get to control exactly when it is considered "ready" (may still be running initialization), but this is probably close enough, and keeps all the implementation inside the JRE. This would likely be an easy patch to write. Jaroslav, Jesse, If you trying to find a complete solution then, please, also take into account the results of the following activities: * https://bugs.openjdk.java.net/show_bug.cgi?id=100094 (the same is here http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6863566) Pushed changes in the jdk7/awt/jdk do not unset the DESKTOP_STARTUP_ID variable. I am not sure about integration of such changes in all implementations of the the JRE 6 that should be supported by the NetBeans on the Linux platforms. * http://netbeans.org/bugzilla/show_bug.cgi?id=169290 Core NBI engine provides own .desktop file where StartupNotify is not set now. Probably, we should have common approach in the NetBeans to have correct integration with all Linux platforms that meet with the standards of the freedesktop.org, including, but not limited to, the Startup notification protocol specification, the Desktop Entry Specification, etc. |