[
https://issues.apache.org/jira/browse/NETBEANS-3249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998515#comment-16998515
]
Matthias Bläsing edited comment on NETBEANS-3249 at 12/21/19 9:05 AM:
----------------------------------------------------------------------
I tried to reason what is happening here and this gave me an indication:
https://discussions.apple.com/thread/4088190
There are other sources, but all basicly say, that on a mac, there are various
unix folders, that are just symlinks into a subfolder "/private". In our case
_/var_ is most probably a symlink to _/private/var_. So I think this is what
happens:
_ChromeBrowserImpl#createBlankHTMLPage_ creates the pseudo file by invoking
_File#createTempFile_ this most probably returns a File like in the original
bug report:
file:///var/folders/4l/3*2.html
now Chrome is either clever or plain stupid and resolves the symlink to:
file:///private/var/folders/4l/3*2.html
running _ls -l_ on the root folder should make it possible to verify this.
If that is the case, we can try to use the same approach as I used in the git
module:
/ide/libs.git/src/org/netbeans/libs/git/jgit/commands/MoveTreeCommand.java
{code:java}
/**
* Files inside symlinked folders need to be resolved to their correct
* location.
* <p>
* If the supplied {@code input} file exists, the "real path" according to
* the NIO implementation will be returned. In the case of an error or if
* the file does not exist or the input was null, the original object will
* be returned.
* </p>
*
* @param input file to normalize
* @return the normalized file
*/
private File tryNormalizeSymlink(File input) {
if(input == null) {
return input;
} else if (input.exists()) {
try {
return input.toPath().toRealPath().toFile();
} catch (IOException ex) {
return input;
}
} else {
return input;
}
}
{code}
Then we could pass the correct path to Chrome/Chromium and the root cause would
be fixed.
I'm just not an apple fan and don't own apple hardware, so it would be great if
this could verified by an apple user.
was (Author: mblaesing):
I tried to reason what is happening here and this gave me an indication:
https://discussions.apple.com/thread/4088190
There are other sources, but all basicly say, that on a mac, there are various
unix folders, that are just symlinks into a subfolder "/private". In our case
_/var_ is most probably a symlink to _/private/var_. So I think this is what
happens:
_ChromeBrowserImpl#createBlankHTMLPage_ creates the pseudo file by invoking
_File#createTempFile_ this most probably returns a File like in the original
bug report:
file:///var/folders/4l/3*2.html
now Chrome is either clever or plain stupid and resolves the symlink to:
file:///var/private/folders/4l/3*2.html
running _ls -l_ on the root folder should make it possible to verify this.
If that is the case, we can try to use the same approach as I used in the git
module:
/ide/libs.git/src/org/netbeans/libs/git/jgit/commands/MoveTreeCommand.java
{code:java}
/**
* Files inside symlinked folders need to be resolved to their correct
* location.
* <p>
* If the supplied {@code input} file exists, the "real path" according to
* the NIO implementation will be returned. In the case of an error or if
* the file does not exist or the input was null, the original object will
* be returned.
* </p>
*
* @param input file to normalize
* @return the normalized file
*/
private File tryNormalizeSymlink(File input) {
if(input == null) {
return input;
} else if (input.exists()) {
try {
return input.toPath().toRealPath().toFile();
} catch (IOException ex) {
return input;
}
} else {
return input;
}
}
{code}
Then we could pass the correct path to Chrome/Chromium and the root cause would
be fixed.
I'm just not an apple fan and don't own apple hardware, so it would be great if
this could verified by an apple user.
> Chrome connector connection with NetBeans
> -----------------------------------------
>
> Key: NETBEANS-3249
> URL: https://issues.apache.org/jira/browse/NETBEANS-3249
> Project: NetBeans
> Issue Type: Bug
> Reporter: Geertjan Wielenga
> Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Here's a fix for the Chrome connector issue:
> https://netbeans.org/bugzilla/show_bug.cgi?id=245227#c15
> Also, in an e-mail by Rob Cooper, the reporter in the above, to me:
> {quote}The file I updated is -
>
> webcommon/extbrowser.chrome/src/org/netbeans/modules/extbrowser/plugins/ExternalBrowserPlugin.java
> I updated method urlToString(...) as follows -
> private String urlToString(URL url) {
> String urlStr;
> String badStart = "file:/private/var/";
> String goodStart = "file:/var/";
> try {
> // try to 'normalize' the URL
> urlStr = url.toURI().toASCIIString().toLowerCase();
> } catch (URISyntaxException ex) {
> urlStr = url.toExternalForm();
> }
> if (urlStr != null && urlStr.startsWith(badStart)) {
> return goodStart + urlStr.substring(badStart.length());
> }
> return urlStr;
> }
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
