This is not issue related to localized nb.
Run on solaris or windows in ja or zh locale.
create project with mbyte in first of its name (since this creates a dir
with mbyte, it might be that just having dir with mbyte might cause it).
choose generate javadoc from explorer menu
the javadoc is generated and it shows in output window the url that will be
but on windows, the url is not found, since in windows address bar, the mbyte
its looking for is not correct - see gifs of that vs explorer/output window
view of project name/dir -- and it looks like the second ascii letter is
on solaris, mozilla goes away when trying to browse to this incorrect url.
But if browse directly to the url shown in output window, its ok.
and if no mbyte is used, its ok.
No exceptions are seen in terminal or messages.log.
Created attachment 28111 [details]
corrupted mbyte in browser address bart
Created attachment 28112 [details]
correct view of mbyte in explorer and output window
Created attachment 28113 [details]
another view of corrupted mbyte in browser
Created attachment 28114 [details]
correct view of mbyte project name
If I use internal swing browser, everything works correctly. The problem seems
to be in external browser module, which incorrectly translates internal url to
Created attachment 28210 [details]
Mozilla browser can show javadoc corretly. Look at the javadoc-mozilla
screenshot attachment. Character encoding was set Chinese simplified (GBK)
Created attachment 28211 [details]
In Swing Browser
Created attachment 28212 [details]
Warning from Mozilla
Created attachment 28213 [details]
Mozilla on Linux
Created attachment 28214 [details]
Source window from mozilla.
Created attachment 28216 [details]
Allert from Firefox
This is more complected then I thought at first time and I think that the bulk
of the problem lies outside NetBeans. It depends on the OS, encoding and browser.
What I discovered during evaluation:
1) Swing browser - works OK. It's because it's running in the same VM -> the
same encoding has as NetBeans. You can see SwingBrowser.png
2) Mozilla on Linux - at first is displayed alert (mozilla-alert.png). But when
you click on ok, Mozilla start and show the left frame (mozila-window.png). So
the alert is not for the index page but for the second frame. You can see the
mozilla-source.png, where are not good the relative links. It's the reason, why
mozilla in this case is not able to open the second frame.
3) Mozilla on Windows - works correctly. Only Java doc doesn't generate the meta
tag with the needed encoding.
4) Firefox - see the alert from firefox (firefox.png). Firefox is not able
recognize the url, which is sand from NetBeans.
I don't really know what to do with this issue. This issue consists from more
problems. Fixing all these aspects it will be very dangerous for NB 5.0, and
still we are not able some small parts fix now. These problems were ther for
long time, so I suggest to wave this issue.
The waiver was approved. Need to mention in documentation or rel. note.
Huh, what's this. Why me? :) This module is part of ide cluster and as such,
this issue is not supposed to be fixed into 5.5, right?
Isn't this similar (or duplicate) of issue 77798 ?
Re targetting NB 5.5 or trunk: this should be fixed in NB 5.5, according to the
NB 5.5 quality criteria. This is code maintained by the J2EE team.
I did again the evaluation and I still think as I wrote in January that this is
not connected with the NetBeans but with the browsers. The issue #77798 cover
exactly the same problem only the invocation is different. So I'm marking this
issue as duplicate of issue #77798.
*** This issue has been marked as a duplicate of 77798 ***