Also, switch to use the new divider styles in most places. The remaining usage of the old "OakCreateLine" functions are in the OakChooser windows. These will be refactor for better dark mode support next.
This introduces the `OakBackgroundFillViewStyle` enum with styles that are dark mode aware and should lead to more consistent use between UI elements in the future. Also, convert OTVStatusBar and OFBHeaderView to use the new style enum.
This is done by setting the ‘disableJavaScriptAPI’ key to ‘true’ in the tmCommand file.
The rationale behind this is that a command like “HTML → Show Preview” is using the HTML output view with user data which should not have access to the special TextMate JavaScript object, for example a user may have a `<script>` tag that loads JavaScript from a CDN, and such script would effectively have shell access to the user’s machine.
Most of these layout changes are related to the common pattern we used to set constraints for "dividers", where one of the dividers is specified to be connected to both edges of its superview then setting the other dividers' constraints to have equal widths (e.g., @"H:|[divider(==divider2,==divider3)]"). On 10.12, this now appears to result in ambiguous layout. We can resolve it by connecting at least one of the edges for each divider to its superview.
Although this is actually deprecated in 10.10, new APIs are available in 10.9 and it will make addressing deprecation warnings when upgrading to 10.10 easier.
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.
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.
