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.
|Summary:||Handling of internal URL w/ extbrowser|
|Product:||platform||Reporter:||Jesse Glick <jglick>|
|Component:||Help System||Assignee:||Jaroslav Havlin <jhavlin>|
|Severity:||blocker||CC:||issues, jeri, jtulach, pjiricka, rmatous|
|Issue Type:||ENHANCEMENT||Exception Reporter:|
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 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?
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. 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.
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: 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.
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: URL.
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 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.
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.