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.

Bug 31363 - Handling of internal URL w/ extbrowser
Summary: Handling of internal URL w/ extbrowser
Status: NEW
Alias: None
Product: platform
Classification: Unclassified
Component: Help System (show other bugs)
Version: 3.x
Hardware: PC Linux
: P3 blocker (vote)
Assignee: Jaroslav Havlin
Keywords: API
Depends on:
Reported: 2003-02-22 14:00 UTC by Jesse Glick
Modified: 2011-09-01 16:04 UTC (History)
5 users (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2003-02-22 14:00:22 UTC
I just realized (dev feb 21) that it does not work
to browse an internal URL using the external
browser. E.g. configure some external browser such
as Mozilla, then create a .url (bookmark) like


Opening this URL will just try to send it right to
Mozilla, which of course will not work.

What is desired is for the httpserver to rewrite
this to some
URL and show that, of course.

But it cannot happen currently, because httpserver
only exports a URLMapper, which is not capable of
mapping one URL to another *unless* that URL
corresponds to a FileObject. For some protocols
like nbdocs:, it doesn't.

Any ideas? Is this solvable? Should URLMapper be
extended to have

public abstract URL getBetterURL(URL url, int type);

(actually not abstract but a dummy body, for
compatibility) and a matching static utility method?
Comment 1 Jesse Glick 2003-03-13 15:04:21 UTC
Raising priority as it may interfere with possible Docs improvements.
Comment 2 _ rkubacki 2003-03-13 15:21:56 UTC
What improvements do you mean?
Comment 3 Jesse Glick 2003-03-13 15:45:05 UTC
Ability to have .url files using nbdocs: protocol. There are
workarounds, but it would be nice to not have to worry about it.
Comment 4 Martin Grebac 2004-01-23 15:02:23 UTC
 Hmm, I don't understand. What else is a result of nbdocs:/ protocol
than fileobject ?
 Could you give me some points where I could get more info about
nbdocs:/ ?

Comment 5 Jesse Glick 2004-01-23 15:22:06 UTC
nbdocs protocol is defined by the core/javahelp API module, i.e.

Easily reproduced problem. E.g. set system browser to Swing (internal)
browser. Create a bookmark


Open it. It will show

"Finding Information About the IDE
No help is mapped to this specific feature.

Now set system browser to e.g. Mozilla. It tries to literally load the
nbdocs: URL in a Mozilla browser window, which of course does not
work, since that URL has meaning only inside the IDE. URLMapper
normally takes care of such remappings, but *only* if the content of
the URL is backed by a FileObject (e.g. nbfs/nbhost).

Some other URL protocols behave similarly, e.g.


I only mentioned nbdocs because I was actually trying to display pages
from the online help in the external browser and it did not work.
Comment 6 Petr Jiricka 2004-01-23 15:45:53 UTC
Jesse is right, this should work. There is code in extbrowser that
solves this for URLs that are backed by fileobject, see method
URLUtil.createExternalURL(...). This method needs to be enhanced to
also work for the nb* URLs.

The solution probably needs to be to tunnel this resource through the
internal HTTP server somehow, so the server acts as a proxy between
the browser and the IDE. There may be some enhancements needed on the
side of httpserver. Unfortunately, this means that extbrowser will
need to depend on the httpserver module (unless OpenAPI agrees to add
interfaces to support this, in which case there would only be a
provides-requires dependency between httpserver and extbrowser).
Comment 7 Jesse Glick 2004-01-23 15:55:14 UTC
I agree that it is likely that API enhancements in openide are
necessary to support this (if we want to avoid a direct extbrowser ->
httpserver dependency, which I think would be for the best). The issue
should be left in extbrowser though IMHO, since the user-level problem
is that the external browser does not work on such URLs. If you
investigate things and decide you do need an API enhancement e.g. in
URLMapper, just open a new RFE (e.g. in openide/filesystems) marked
'API' and make it block this issue.

It may be too late to solve this for 3.6; the fix would probably be
simple enough, but an API change requires a review etc. I am
downgrading the priority a bit because a user would not normally *try*
to browse such a URL directly; it would only affect the ability of
e.g. the docs team to do some things, which are probably not high
priority for 3.6.
Comment 8 Martin Grebac 2004-01-23 16:02:03 UTC
 Thanks for explanations, now I understand. I know there's a code in
extbrowser that handles external urls, I just didn't realize the
fileobject background.
 So, having read all the comments, I'm setting target milestone to
promo-D, and will most likely submit the RFE soon.
Comment 9 Jesse Glick 2004-10-25 17:33:14 UTC
This can be fixed in 4.0, without API changes; please reevaluate. In
4.0 all files on disk should be backed by a FileObject so extbrowser
should be able to work with them.
Comment 10 Martin Grebac 2004-10-26 15:06:55 UTC
Yes, this is fixable without api changes, but I don't have time to fix
this for 4.0.
Comment 11 Jesse Glick 2005-11-04 19:19:57 UTC
NbinstURLMapper should already be producing a FileObject for every valid nbinst
URL. So just need extbrowser to map URL -> FileObject -> (EXTERNAL/NETWORK) URL.
Comment 12 Petr Jiricka 2006-01-06 08:03:42 UTC
New location for the nbdocs protocol documentation is (I believe) this one:

This issue could be related to issue 70784.
Comment 13 Jesse Glick 2006-01-06 22:01:49 UTC
The special-case treatment in issue #70784 could perhaps be extended to handle
nbdocs, nbres, and nbresloc as well. But I would suggest some more general fix
which does not hardcode special URL protocols - probably trying to use URLMapper
to convert an abstract URL to a FileObject and then back to a file: or jar:file:
Comment 14 Petr Jiricka 2006-01-06 22:56:43 UTC
That would make sense (the latter). Currently nbdocs and such map to null using
URLMapper. Does it mean that the respective modules that provide the stream
handler (e.g. javahelp) would be also responsible for providing the URLMapper?
Comment 15 Jesse Glick 2006-01-06 23:25:32 UTC
"Does it mean that the respective modules that provide the stream handler (e.g.
javahelp) would be also responsible for providing the URLMapper?" - yes, exactly.
Comment 16 Petr Jiricka 2006-01-07 07:37:55 UTC
Ok, reassigning to core/help system.
Comment 17 Jesse Glick 2006-01-07 17:27:17 UTC
Hold on a moment. Yes it means that core/javahelp is responsible for providing
the right URLMapper impl. However we need some assurance that the extbrowser
module will actually use it when it is available. Currently AFAIK it does not,
meaning the primary bug is still in extbrowser.
Comment 18 Petr Jiricka 2006-01-09 12:21:58 UTC
I believe extbrowser does the right thing here, see 


It checks whether the input URL can be opened in external browsers (i.e., if the
URL is either file, or if it is jar and the browser supports jar urls), and if
not, maps the URL to a FileObject using URLMapper, and then goes through all
registered URLMappers until it finds one that maps the fileobject to a usable URL.
Comment 19 Lukas Hasik 2008-04-10 21:23:06 UTC
moving opened issues from TM <= 6.1 to TM=Dev
Comment 20 Lukas Hasik 2008-09-09 16:14:10 UTC
TM == 6.5, does it mean that it will be fixed for 6.5? After all the years when it is opened...
Comment 21 Antonin Nebuzelsky 2008-11-14 15:17:47 UTC
Reassigning to the new "core/help system" owner obarbashov.
Comment 22 Alexei Mokeev 2009-03-05 13:57:34 UTC
Moving JH issues to Victor.
Comment 23 Alexei Mokeev 2009-04-13 10:16:56 UTC
Better handling of bookmarks with internal URLs using external browser really looks like enhancement for me.
Currently user not even able to create/edit such a file from IDE.