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 pass URL http://java.sun.com/javase/6/docs/api/java/lang/String.html#String(char[], int, int) to HtmlBrowser.URLDisplayer.getDefault().showURL() but it fails with message "Error: Failed to send command: 500 command not parseable". I create url with new URI(urltext).toURL() thus it should be properly encoded. The same I get when I run firefox -remote "openurl(http://java.sun.com/javase/6/docs/api/java/lang/String.html#String(char[], int, int))" from the command line. The problem seems to be in round brackets in fragment of URL. Konqueror or browsers on Win platform work OK. Possible workaround could be to escape round brackets for firefox on unix.
Weird, isValid() is called on a wizard panel before readSettings(). I have committed a workaround, which will be available in GWT4NB 1.3.4 ==[IDE]== May 22, 2007 11:39:47 AM Committing... ci --force-log -F /tmp/svn_message_65490 --username tomslot --password ******* --non- interactive --config-dir /Users/tomslot/.netbeans/6.0m9/config/svn/config --targets /tmp/svn_checkin_65491 Sending /Users/tomslot/SUN/src/nb/contrib/gwt4nb/src/org/netbeans/modules/gwt4nb/GWTConfigPanel.java Transmitting file data . Committed revision 61. ==[IDE]== May 22, 2007 11:39:57 AM Committing... finished.
Sorry, I accidently closed a wrong issue
Reproducible, Im not happy about adding one more hack to the extbrowser module...
Fixed. Checking in SystemDefaultBrowser.java; /cvs/extbrowser/src/org/netbeans/modules/extbrowser/SystemDefaultBrowser.java,v <-- SystemDefaultBrowser.java new revision: 1.12; previous revision: 1.11 done Checking in URLUtil.java; /cvs/extbrowser/src/org/netbeans/modules/extbrowser/URLUtil.java,v <-- URLUtil.java new revision: 1.15; previous revision: 1.14 done
You cannot blindly use URLEncoder.encode(anchorOrg, "UTF8") since it expects plain text on input but URL you get in the extbrowser should be already encoded. I will try to show the problem on not so complex URL. 1. Following URL is RFC 2396 compliant. But in case I send it to FireFox on Linux it fails. http://java.sun.com/javase/6/docs/api/java/net/URLDecoder.html#decode(java.lang.String,%20java.lang.String) 2. In case I encode round brackets everything starts to work. http://java.sun.com/javase/6/docs/api/java/net/URLDecoder.html#decode%28java.lang.String,%20java.lang.String%29 3. BUT this is what I get using URL from 1.) after your fix. http://java.sun.com/javase/6/docs/docs/api/java/net/URLDecoder.html#decode%28java.lang.String%2C%2520java.lang.String%29 So I did not ask you to fix invalid URLs in the extbrowser but to resolve the FireFox issue with brackets on unix systems.
The URL you originally provided contained spaces and that was the reason why displaying it failed (I only checked it on Mac, probably on Linux the brackets are also a problem). Anyways, we still need to fix invalid URLs because some users rely on it. Thanks for pointing out the problem with URLs that have been previously encoded.
Sorry, I have not got an encoded URL at hand. Yes, the brackets issue occur on Linux too. IMO you should file issues against clients passing invalid URLs. It is their responsibility to pass valid URLs. To catch these clients URI constructor should help. Maybe some encoding/decoding helper methods in Utilities would help since URLEncoder encodes input too restrictively in order to be valid in html forms. RFC 2396 is not so strict. I would prefer invest time to such helpers rather than to an automatic fixing of passed URLs. Just my 2c.
I am now calling URLDecode prior to calling URLEncode to make sure partially (or fully) encoded URLs are handled properly. /cvs/extbrowser/src/org/netbeans/modules/extbrowser/URLUtil.java,v <-- URLUtil.java new revision: 1.16; previous revision: 1.15
There were other issues where certain browsers did not accept certain RFC 2396 compliant, but "exotic" characters or constructions, URLEncode did a decent job preventing such problems. Anyways, I will look into it again.
*** Issue 76650 has been marked as a duplicate of this issue. ***