The previous name was inspired by WebView’s default API but it sounds like it is just the default implementation with a default baseURL: parameter, hence why I prefer to name it something different.
The problem is that HTML output is loaded from the x-txmt-command protocol, possibly with the “base URL” set to file://$TM_FILEPATH, so protocol-relative URLs like //example.org/main.css would be resolved as file://example.org/main.css.
We now try to detect these URLs (heuristically, since we only see the resolved URL) and (by default) redirect to https.
This commit checks for the presence of NSURLComponents which was introduced in Mac OS X 10.9. On 10.8 this commit has no effect.
Some targets were including headers from frameworks not specified in their link dependencies. For a clean build this could cause an issue because the header was not available at the time of building the target.
The updated link dependencies are also based on what a target’s tests require. Ideally tests would have separate link dependencies, but as we don’t want to maintain this manually, this will have to wait until the build system automatically handles link dependencies.
Currently the commit command uses constants from the CommitWindow framework but should actually not be linked with it. However, the optimizer will strip dead code, so it should not result in much if any difference in the resulting binary and does solve a build dependency issue.
With the 10.11 SDK we get a warning about this initializer not calling super, however, we do not intend for instances of this class to be created, which is why we had the dummy initializer.
We should remove this class entirely, as it’s a workaround for a problem that was fixed a long time ago, but I haven’t yet tested if there are still bundles using the (legacy) tm-file: URL scheme.
We call `fileURL` here but the method doesn't actually exists (it's actually a property with the getter `isFileURL`). The URLs we obtain from NSOpenPanel are paths so it's probably safe to get the path without checking if it's a proper file URL.
Using a relative URL in a command with HTML output will be relative to our custom URL scheme which could result in stalling the output, as we did not handle “not found”, so WebKit would wait for data until a timeout.
This workaround is to avoid a couple of undesired behaviors in the `HTMLOutputWindow` when the web page implements keyboard commands such as Git → Browse Annotated File (Blame). Namely, when using the keyboard commands, we would always receive an NSBeep. Also, fixed an issue when these key commands may conflict with menu keys. See comment in the commit for details.
