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.
this might be related to some previous limitations of uml report on solaris with mozilla, but since now for nb6 is the new project and file encoding properties and functionality, am filing here since it might be related to that. a similar issue has been seen in java projects related to finding javadoc, see 118435. solaris, ja locale uml java platform model project (not rev engineer project though it happens in that case also) since uml has not impelemented a project encoding property, the current global project encoding property of euc-jp am guessing is not a problem (118435 happens when project encoding is utf8 or euc-jp (euc-jp is encoding of solaris ja locale) 1. create uml java platform model project. 2. have the project and its path have multibyte in their names 3. choose class diagram 4. drop a class on it and give name with multibyte, also an attribute with name that has mbyte. 5. save 6. generate report. 7. initial firefox window shows ok, see first gif 7. click on the name of the class, under All Elements section, and there is error window that says it can't find the html page - see second gif. 8. changing the browser encoding does not help - its at japanese euc when invoked. This does not happen using IE on windows but does happen on firefox using windows. Also, but not related, if IE is open, uml report does not open a new tab or a new window (depending on how tab options are set up) BUT this is not uml issue I think since happens using javadoc also and am guessing its my setup ? an issue on this was filed under javadoc.
Created attachment 50916 [details] image
Created attachment 50917 [details] image
This issue occurs with firefox, on both Solaris and Windows. IE and Firefox treat multibyte file URI differently. Firefox seems to use specified page encoding and href to construct file uri for the hyperlink. Using UTF-8 to encode report works for both IE and Firefox. The fix for the described scenario has been tested on Windows Vista.
reopening, does not work on solaris, which is where this was originally seen. I dont think project encoding prop is an issue here since this is java model and not associated with any project. the browser encoding is now set to utf-8 but its still same problem as firefox states it cant find the path to the file, as in original problem. ken.frank@sun.com
using later .08 version of firefox vs 03 used before, problem is the same.
Development testing indicates the problems is fixed for firefox on windows, both XP and Vista. There is still a problem on Solaris which we believe is a browser problem rather than a problem in the generated report. We will provide a FAQ for that.
since problem is still on solaris using firefox, should this have been resolved since that is where also issue was seen ? or is it that its firefox problem outside of uml and thus can't be fixed so its needs to be resolved in that context ? also, has the faq mentioned been provided for this ? if above is true, it can be verified. ken.frank@sun.com
please answer questions in last comment before this one and then can verify this. ken.frank@sun.com
I'd like to verify this; to summarize, the fix was for windows but not for unix per se since problems in firefox on unix are the actual cause ? we can make a faq entry about this.
Tested recent trunk build 20080804 on Solaris with Firefox 2.0.0.17pre, the issue is gone.
based on Sheryl's additional comments, am placing in verified state - it was tested with the 20080804 build on Solaris with Firefox 2.0.0.17pre under locale zh and zh_CN UTF8, the issue is no longer reproducible on Firefox ken.frank@sun.com