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?
Raising priority as it may interfere with possible Docs improvements.
What improvements do you mean?
Ability to have .url files using nbdocs: protocol. There are
workarounds, but it would be nice to not have to worry about it.
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 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.
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).
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.
Thanks for explanations, now I understand. I know there's a code in
extbrowser that handles external urls, I just didn't realize the
So, having read all the comments, I'm setting target milestone to
promo-D, and will most likely submit the RFE soon.
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.
Yes, this is fixable without api changes, but I don't have time to fix
this for 4.0.
NbinstURLMapper should already be producing a FileObject for every valid nbinst
URL. So just need extbrowser to map URL -> FileObject -> (EXTERNAL/NETWORK) URL.
New location for the nbdocs protocol documentation is (I believe) this one:
This issue could be related to issue 70784.
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:
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?
"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.
Ok, reassigning to core/help system.
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.
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.
moving opened issues from TM <= 6.1 to TM=Dev
TM == 6.5, does it mean that it will be fixed for 6.5? After all the years when it is opened...
Reassigning to the new "core/help system" owner obarbashov.
Moving JH issues to Victor.
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.