Bug 84092

-> sunappserv

I could not reproduce.
When you can, please attach the entire exception and reopen the bug.
Also, code in 6.0 is older than 5.5. 5.5 is the live branch for Java EE development.

Created attachment 33628 [details]
stack-trace

Please see attached stack-trace.

Not sure it is related to GlassFish, but more on the known browser from the IDE.
See the message:
Annotation: Could not access the URL through the external browser. Check the
browser configuration. From the Tools menu, choose Options. Click 'Classic View'
button, expand IDE Configuration/Server and External Tool Settings node, then
expand Web Browsers and choose valid browser.
"
Can you tell which browser is configured there and how?

Any chance to have more stack trace info (if any)?

I have "default browser" selected (which is FireFox for me). If you tell me how
to get more stack-traces I'll give them to you :)

:-)

Can you test this for me: install GF in a non space dir, register it:
Do you see the same behaviour?

Also, can you confirmed you are not using Windows Vista? We have several bugs
around that on latest (yet to be released) OS.

Cannot reproduce.
Can you test other ways to display the broswer from netbeans? For exalp,e in the
welcome screen links or by running an app on tomcat?

You're right. View -> Web browser causes the failure regardless of Glassfish.
This is 100% reproducible under Windows XP and FireFox ("C:\Program
files\Mozilla Firefox"). Can you reproduce under a similar environment on your
end? BTW: This would be a regression because it used to work in 5.0 and 6.0.

Please bump to P2, is you think this is blocking you.
on my PC, it works with firefix in a dir with space

Bumped up to P2 as this occurs frequently and is a regression. What information
do you need from my end to track down the underlying problem?

It would be helpfull if you could run the IDE with following parameter:
-J-Dorg.netbeans.modules.extbrowser=-1

Either pass it from command line or add this to a netbeans.conf file. This will print extra debug 
information into messages.log file located in your user directory containg IDE specific data (Help|About|
Detailshows where is Userdir). Then please attach the log file to the issue.

Created attachment 33769 [details]
extra logging

I've attached the log. I don't understand why you've attached the keyword RANDOM
to this issue as it is 100% reproducible on my end.

thanks for instant reply. By RANDOM I mean it is not always reproducible at any end and we don't know 
the exact conditions to reproduce it yet. As a matter of fact computers are fairly deterministic :-)

But... it isn't random :) Are you saying you can't reproduce this on your end
under Windows/FireFox by running "View -> Web browser" from inside Netbeans?

Yes, I cannot reproduce it :-(

Okay, looks like it has to do with the proxy settings. If I change from "use
system proxy" to "none" then suddenly the problem goes away. How do I expose
what proxy settings Netbeans sees?

PS: I verified that this issue occurs on a clean userdir on both JDK 1.5.0_07
and JDK 1.6.0 b97.

Yet another information can be obtained with
-J-Dorg.openide.execution.NbProcessDescriptor=-1

Can you attach IDE log with output from this test?

It seems that -J-Dorg.openide.execution.NbProcessDescriptor=-1 doesn't produce
any extra output. Is there another switch we can use?

My fault - I was looking into trunk sources. -J-DIDE-Exec=-1 in release55 and
-J-Dorg.openide.execution.NbProcessDescriptor.level=500 in trunk (upcoming 6.0).

IDE-Exec=-1 doesn't seem to provide enough information. The only extra logging I
get is:

[IDE-Exec] Running: [C:\Program, http://www.netbeans.org/]

I doubt this is enough for you to figure out why it is happening. Is there more
logging I can enable?

BTW: Turns out I was wrong, this bug has nothing to do with the proxy settings.
The only thing that matters is whether Tools | Options | General | Web Browser
is set to "FireFox" (which works) or "<Default System Browser>" which fails. The
odd thing is that FireFox *is* my default browser :)

There might be some problem with reading from Win registry. I suggest to enhance
SystemDefaultBrowser.defaultBrowserExecutable with some additional logging.
Namely what is returned from native method and catch(NbBrowserException)
handling where we can find what is wrong. 

Tomasz: will you create a patched build or should I add it directly to trunk so
that Gili can test trunk build (with JDK1.5 because 1.6 uses different impl in
trunk).

That won't work. As I originally mentioned, this problem does not occur in trunk
but it does occur in 5.5. So either you add more logging into 5.5 or you try
diffing the code against trunk and find out what is different in 5.5 which could
be breaking it.

Created attachment 34234 [details]
NB55 external browser module printing additional debug info

Please swap the attached file with 'ide7/modules/org-netbeans-modules-extbrowser.jar' on your local NB 
installation, so that we get additional debug info.

Close your web browser before trying. Btw. does this problem also occur when your browser is already 
running?

Can you reproduce it on NB 6.0 run on JVM 5.0?

The new log gives me:

NbDdeBrowserImpl.getDefaultOpenCommand ()='C:\Program Files\Mozilla
Firefox\firefox.exe -url "%1"'

Looks like you should be surrounding the path up to firefox.exe with separate
quotes as well as quoting %1.

This value is taken from Windows registry. We have tried on a number of Windows machines on our end 
and the returned string always included quotes.

Obviously Windows is able to handle the path correctly with and without quotes and we should be able 
to do the same.

We still want to know in what circumstances the quotes are not set in the registry in order to set 
appropriate priority for this issue. We will not aim to fix it in the 5.5 release unless it concerns a large 
group of users, because the fix would be risky at this stage.

gtzabari, can you think of anything specific about your Firefox installation? What version is it and how 
did you switch between default browsers (if you did)?

The workaround is to use registry editor to add quotes to the firefox path.

Removing the RANDOM keyword as we finally know how to reproduce it.

Gili, please confirm whether the workaround works for you, after that let's
downgrade to P3. Thanks.

You're going to have to tell me which registry entry to try changing because
there are many of them that contain firefox.exe and the ones I've tried changing
did not fix anything.

Instead of defering fixing this issue, why don't you compare the current code to
that of 5.0 or 6.0? Both have been working for me perfectly for many months so
unless other users reported problems with them I would think it would be both
easy and safe for you to merge their changes into 5.5.

What version of Firefox do you use now? I guess you will have the same problem
in NB5.0 at this moment. 

NB6.0 can work well with your firefox if you run IDE on JDK6 but likely will
fail in the same way on JDK5. We are not backporting this part of code from
trunk into 5.5 because 5.5 is already in high reristance and there are some
other problems (like pending bugs in JDK causing crash).

The key we are looking for is found in two steps: HKEY_CLASSES_ROOT\.html
contains name of app that is associated as default to .html files (something
like FirefoxHTML). Than HKEY_CLASSES_ROOT\<name_of_this_app>\shell\command\open
contains actual commad string that is split into executable and args. 

I am using FireFox 1.5.0.7. You are right NB5.0 and NB6.0 both fail the same way
using JDK 1.5 and NB6.0 works with JDK 1.6.

NB6.0 "View Browser" does nothing, contrary to NB5.0 that actually brings up the
browser. The only way to bring up the browser in NB6.0 is to run a Web project.
Should I open up a separate bug report for this?

For me, .html was associated with MyHTMLfile and MyHTMLfile/Shell/Open/Command
had the FireFox path without spaces. Once I manually added the spaces the
problem went away.

downgrading to P3 as this problem concerns a small group of users and a workaround exists. The 
problem will targeted in the 6.0 release.

It seems that this issue is obsolete now. Closing. Please reopen with up-to-date information if you experience it again.