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.
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 nbdocs:/org/netbeans/modules/usersguide/pending.html 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 http://localhost:8082/etc./etc./org/netbeans/modules/usersguide/pending.html 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:/ ?
nbdocs protocol is defined by the core/javahelp API module, i.e. http://www.netbeans.org/download/dev/javadoc/JavaHelpAPI/org/netbeans/api/javahelp/doc-files/api.html Easily reproduced problem. E.g. set system browser to Swing (internal) browser. Create a bookmark nbdocs:/org/netbeans/modules/usersguide/pending.html 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. nbresloc:/org/netbeans/modules/java/resources/Main.html 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 fileobject background. 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: http://www.netbeans.org/download/dev/javadoc/org-netbeans-modules-javahelp/org/netbeans/api/javahelp/doc-files/api.html 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: URL.
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 extbrowser/src/org/netbeans/modules/extbrowser/URLUtil.java 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.