Bug 76970

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&CLIAssignee: Jaroslav Tulach <jtulach>
Status: RESOLVED FIXED QA Contact: issues <issues.netbeans.org>
Priority: P3 CC: abadea, anebuzelsky, av-nb, jglick, mpetras, phejl, pjiricka, vvg
Version: 5.x   
Target Milestone: 6.x   
Hardware: PC   
OS: Linux   
Whiteboard: issue_reviewed
Issue Type: DEFECT Exception Report:

Description mhagberg 2006-05-26 19:31:43 UTC
Running suse linux enterprise desktop (SLED) 10 (new installation)
Using Firefox 1.5.0.3

This issue is similar to issue 76650, except that rather than trying to show
javadoc for a class, I am trying to run a web application.

Right after installing NB 5.0, and after reassigning firefox as the primary
browser in the options window, I opened a project created in version 4.1 running
on Novell Linux Desktop 9, and tried to run it by hitting F6.  Initially, with
the default run string, <</usr/bin/firefox -remote "openURL({URL})">>, nothing
seemed to happen, unless a browser was already open.  I assume that the
"-remote" option has changed behaviour in this browser version.  After changing
the run string to <</usr/bin/firefox {URL}>>, I found that firefox opened and
ran the web app, but upon exiting from the browser, a dialog box displayed
saying "cannot execute /usr/bin/firefox..." and further explaining how to select
a browser that did exist (even though the IDE had just opened that very browser).

After much troubleshooting, I decided to "give up" and try Netbeans 4.1 to open
and run the webapp, with basically the same steps, and unfortunately, the same
message box upon closing the browser.

Taking advice from issue 76650, below is the relevant part of messages.log, when
the 5.0 IDE is run with /path-to-ide/bin/netbeans
-J-Dorg.netbeans.modules.extbrowser=-1:

[org.netbeans.modules.extbrowser] External url:
http://localhost:8084/report/pipeline/
[org.netbeans.modules.extbrowser] Executable:
org.openide.execution.NbProcessDescriptor@d44b8ee2
[org.netbeans.modules.extbrowser] Retried: false
[org.netbeans.modules.extbrowser] Retries: 5
[org.netbeans.modules.extbrowser] Time: 1148665121397
[org.netbeans.modules.extbrowser] Retried: false
[org.netbeans.modules.extbrowser] Retries: 4
[org.netbeans.modules.extbrowser] Time: 1148665122400
[org.netbeans.modules.extbrowser] Retried: false
[org.netbeans.modules.extbrowser] Retries: 3
[org.netbeans.modules.extbrowser] Time: 1148665123404
[org.netbeans.modules.extbrowser] Retried: false
[org.netbeans.modules.extbrowser] Retries: 2
[org.netbeans.modules.extbrowser] Time: 1148665124408
[org.netbeans.modules.extbrowser] Retried: false
[org.netbeans.modules.extbrowser] Retries: 1
[org.netbeans.modules.extbrowser] Time: 1148665125412
[org.netbeans.modules.extbrowser] Retried: false
[org.netbeans.modules.extbrowser] Retries: 0
[org.netbeans.modules.extbrowser] Time: 1148665126417
[org.netbeans.modules.extbrowser] Command not finished yet



All of this leads me to believe that:

1) the version of the IDE doesn't seem to be the main issue.

2) the new version of Firefox is somehow either not returning a value that
netbeans is expecting, or is not returning a value at all.

3) it is possible that the "run string" for this particular browser may need to
be different than for previous versions of firefox in order to get expected
behavior, or possibly firefox has broken communication altogether in this respect.
Comment 1 robtdavis 2006-08-17 17:54:27 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
Comment 2 Tomasz Slota 2006-09-11 17:03:30 UTC
confirmed and reproducible, we will consider priority upgrade to P2
Comment 3 Tomasz Slota 2006-09-12 10:28:49 UTC
Unfortunately there seem to be no working way of passing URL to a running Firefox on OS X (see issue 
82040)
Comment 4 Karthikeyan Rajeswaran 2007-07-08 01:21:24 UTC
Reported for 6.0M10 at http://www.netbeans.org/servlets/BrowseList?list=nbusers&by=thread&from=798642
Comment 5 Petr Jiricka 2007-11-01 23:06:39 UTC
So does this happen only with Firefox 1.5.x, or does this also happen to anyone with Firefox 2.0.x? Thanks.
Comment 6 Erno Mononen 2007-11-02 12:29:17 UTC
Works for me at least with FF 2.0, but I'm running Ubuntu not SUSE.
Comment 7 Andrei Badea 2007-11-02 14:05:39 UTC
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.
Comment 8 Petr Hejl 2007-11-02 15:00:53 UTC
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.
Comment 9 Petr Jiricka 2007-11-02 15:09:29 UTC
Ok, setting target milestone to 'future'.
Comment 10 robtdavis 2007-11-02 17:56:25 UTC
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.
Comment 11 puce 2008-01-02 13:15:07 UTC
The same poblem here with openSUSE 10.3 and NetBeans IDE 6.0
Comment 12 puce 2008-01-02 13:20:14 UTC
The same problem here with openSUSE 10.3 and NetBeans IDE 6.0
Comment 13 rcasha 2008-06-13 08:58:53 UTC
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.
Comment 14 Karthikeyan Rajeswaran 2008-07-17 23:43:38 UTC
*** Issue 122784 has been marked as a duplicate of this issue. ***
Comment 15 Karthikeyan Rajeswaran 2008-07-17 23:45:38 UTC
*** Issue 114706 has been marked as a duplicate of this issue. ***
Comment 16 Karthikeyan Rajeswaran 2008-07-17 23:46:19 UTC
*** Issue 139077 has been marked as a duplicate of this issue. ***
Comment 17 Karthikeyan Rajeswaran 2008-07-18 00:01:20 UTC
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.
Comment 18 puce 2008-07-18 09:40:17 UTC
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
Comment 19 Michel Graciano 2008-07-18 16:29:32 UTC
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.
Comment 20 puce 2008-07-18 16:46:48 UTC
> 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
Comment 21 Peter Zavadsky 2008-08-28 17:50:04 UTC
*** Issue 124942 has been marked as a duplicate of this issue. ***
Comment 22 Peter Zavadsky 2008-09-02 19:01:17 UTC
*** Issue 82040 has been marked as a duplicate of this issue. ***
Comment 23 Peter Zavadsky 2008-09-03 21:33:55 UTC
*** Issue 141680 has been marked as a duplicate of this issue. ***
Comment 24 Alexei Mokeev 2008-10-21 14:08:43 UTC
This problem is clearly reproducible with NB 6.1 and Fedora 9 and 10. See
https://bugzilla.redhat.com/show_bug.cgi?id=467546
Comment 25 Victor Vasilyev 2008-10-22 19:24:10 UTC
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. 


Comment 26 Peter Zavadsky 2008-12-01 22:31:03 UTC
Passing to launcher to consider the suggestion about DESKTOP_STARTUP_ID.
Comment 27 sunburned 2009-04-05 01:45:45 UTC
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.
Comment 28 Jesse Glick 2009-10-20 16:16:31 UTC
Should not be assigned to issues@ide, that is not an owner.
Comment 29 Alexei Mokeev 2009-10-21 09:10:11 UTC
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.
Comment 30 Jaroslav Tulach 2010-04-01 21:39:33 UTC
Still valid?
Comment 31 Victor Vasilyev 2010-04-02 10:29:43 UTC
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 !).
Comment 32 Jaroslav Tulach 2010-04-02 18:58:49 UTC
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.
Comment 33 Victor Vasilyev 2010-04-05 00:50:18 UTC
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
Comment 34 Jaroslav Tulach 2010-04-05 04:47:54 UTC
Thanks, I am glad I don't need to spend time reading and understanding the spec.
Comment 35 Jesse Glick 2010-04-05 14:24:48 UTC
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.
Comment 36 Victor Vasilyev 2010-04-05 15:49:47 UTC
(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.).
Comment 37 Jaroslav Tulach 2010-04-06 04:31:29 UTC
(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.
Comment 38 Jesse Glick 2010-04-06 12:32:38 UTC
(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.
Comment 39 Victor Vasilyev 2010-04-06 19:07:13 UTC
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.
By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo