[INTERNAL] IDL Help System on macOS with the Safari web browser results in "The operation couldn't be completed. (KCFErrorDomainCFNetwork error 1)" errors
MariM
Synopsis
Use of the IDL Help System on macOS with the Safari web browser results in "The operation couldn't be completed. (KCFErrorDomainCFNetwork error 1)" errors. In summary …
- This issue does not seem new to IDL 8.8; it could be reproduced using IDL 8.7.3.
- By default, Safari prohibits some (undocumented) local file operations. The error occurs when a temporary HTML file created by the IDL Help system attempts to perform a 'file' scheme redirect to the specific IDL Help content. Safari is preventing this.
- A workaround is to enable the Disable Local File Restrictions option in Safari. This workaround could perhaps be documented in product Release Notes, although advising users to disable security features is perhaps questionable.
- There are somewhat related Internet postings over the past couple years of Mac users receiving similar errors when attempting to simply serve local file home pages. In general, resolutions seemed to be (1) use Disable Local File Restrictions, or (2) use a different web browser (like Firefox).
- The IDL Help System redirect technique is documented as required. A future consideration might be to provide an IDL configuration option to serve help content via HTTP from the harrisgeospatial.com Documentation Center avoiding redirects to local file resources.
The Details
Reproducing the Problem
The issue may be reproduced by performing any of the following on macOS …
- online_help, 'file_copy' from an IDL command prompt
- ?!null from an IDL command prompt
- Help > Help Contents from IDL Workbench
Safari displays either …
- Safari can't open the page. The error is: "The operation couldn't be completed kCFErrorDomainCFNetwork error 1.)" (kCFErrorDomainCFNetwork:1), or
- a blank page
This issue does not appear to be a new with IDL 8.8. The errors also occur with IDL 8.7.3. Additionally, there have seemingly been no changes to the IDL Help System between these releases.
IDL Help System Processing
When IDL Help is invoked, idl-core idl_olh.c creates a temporary HTML file in $HOME/.idl/envi/online_help-10-idl_8_8-unix/olh_anchor_redir.html. This file contains the following:
<!--
This file was created by IDL to work around limitations of
the Microsoft Windows ShellExecute() function:
- If you pass ShellExecute() a URL containing an HTML
anchor, it strips the anchor off the URL and the browser
never sees it.
- There are hacks involving the FindExecutable() function
that can trick ShellExecute() into not stripping the anchor,
but they have the unwanted side effect of starting a new
browser instance for each such call.
- You can just skip ShellExecute() and talk to InternetExplorer
directly, but that locks out other browsers and is fairly
difficult as well. Plus, it won't track changes Microsoft may
make to the browser.
In addition, it is used to work around a similar problem on Unix
systems where a URL containing a pipe symbol '|' is interpreted by the
shell and cannot be passed through to the Javascript interpreting the
URL. The help symbol uses the string '|Firstpick' to indicate that the
first topic found in the query should be loaded but this URL cannot
be sent directly to the browser because the shell treats it as a
pipe symbol to control i/o.
Alternatively, you can generate a temporary HTML file containing a
refresh META tag, and pass the URL for that file to ShellExecute().
This is that file.
You can remove this file if you wish. IDL will recreate it whenever it
needs it. The specific situation where that occurs is a call to
ONLINE_HELP that specifies a non-NULL topic and which sets the
BOOK keyword to the name of an HTML file.#
-->
<html>
<!-- saved from url=(0014)about:internet -->
<head>
<meta http-equiv="Refresh" content="0; URL='file:////rsi/engcode/bdavis/darwin/harris/envi56/idl88/help/online_help/help_CSH.htm#FILE_COPY'">
</head>
</html>
The <meta http-equiv="Refresh"> redirect containing the file scheme URL results in the error. Note that the temporary HTML file includes comments on why this redirect technique is required: (1) to work around limitations of the Microsoft Windows ShellExecute() function, and (2) work around a problem on Unix systems where a URL contains a pipe symbol '|' is interpreted by the shell)
Using a Javascript-based approach to perform the redirect made no difference.
File Scheme URLs
This is not at all related to this issue, but it was observed that the file scheme URLs created by idl_olh.c contain 4 leading slashes ('file:////'). Per RFC 8089, they should only contain 3 leading slashes ('file:///'). Clearly web browsers are accommodating the extra slash. See the file URI scheme article on Wikipedia for more information.
Safari "Disable Local File Restrictions" Option
A workaround to the issue is to enable the Disable Local File Restrictions option in Safari. This is accomplishes as follows:
- From the Safari menu bar item, select Preferences…, then click Advanced, check the Show Develop menu in menu bar checkbox, and close the dialog.
- From the Develop menu bar item, check Disable Local File Restrictions
Exactly what local file restrictions are disabled and the associated security risks of doing so do not seem to be documented. Conversely, whatever specific file restriction that is preventing the redirect is also unknown. A query in this regard has been posted on the Apple User Communities Safari forum.
Additionally, some experimentation was formed outside of IDL with simple a simple source "redirect" HTML file and target HTML file located in various locations across file systems. Curiously, there did seem to be some difference in behaviors between the osx_intel20 (macOS 10.14.3 w/ Safari 12.0.3) and osx_intel18 (macOS 10.14.5 w/ Safari 12.1.1) systems. Besides differences in macOS and Safari versions, it seems possible that variations in macOS security settings might be a contributor to those differences. Regardless, the exact cause of the IDL Help System issue, or a potential solution, could not be ascertained.
Related Internet Postings
A number of seemingly related postings were found on the Internet, mostly from Mac users attempting to use a local file as their Safari home page. Here's some of the more interesting posts:
Potential Future Work
Brian G. has suggested that a potential and perhaps somewhat strategic solution to this issue would be to support an IDL configuration option to serve help content online from the harrisgeospatial.com Documentation Center. Although this could not be an option for all users (e.g., those without Internet connections), it could perhaps mitigate this issue for macOS users.