Setting the real base URL (rather than using a file URL pointing to the app's Resources folder) allows relative URLs to work correctly within the article, such as for images, and is compatible with Cross-Site-Origin policies that restrict use of resources outside of the origin domain.
It also implicitly eliminates access to the local file system from within the webview, as the use of a non-file base URL makes WebKit treats the webview's content as being from a remote server, and its default security policy is to then disallow local file access (except with explicit user action, such as drag-and-drop or via an `input` form element).
Note: the base URL is currently typically taken from the feed itself (specifically the "link" feed (channel) metadata). That is controlled by the feed author (or a man-in-the-middle attacker). It should perhaps be validated to ensure it's actually an HTTP/HTTPS URL, to prevent security problems.
The app-specific JavaScripts - used for fixing styling issues and the like - are now formally loaded as extensions to the web page, "user scripts" in WebKit parlance. They're isolated to their own JavaScript world - meaning they can't be seen or manipulated by JavaScript from the feed article itself, and are more secure as a result.
Fixes#4156.
Co-Authored-By: Brent Simmons <1297121+brentsimmons@users.noreply.github.com>
• `xcconfig` `MACOSX_DEPLOYMENT_TARGET` updated to 13.0
• Removed `@available` annotations for macOS < 13.0
• Removed for Big Sur fixes.
This has been built and doesn’t trigger any build settings should be `xcconfig` options.
Both the details and timeline container views were not extending behind the toolbar and thus content would not show when scrolled behind it. Top anchors should anchor to the top of the super view rather than safe area guides and AppKit automatically adjusts the scroll insets for NSToolbar and optionally (if available) NSTitlebarAccessoryViewController. This allows for the divider to appear when content scrolls behind it and for content to "shine through" the translucency of the NSToolbar.
Noticed that the window size wasn't returning the new value and that's why using the window size to calculate the size to restore it to we were incrementing the original size by one.
Not sure if this breaks the fix that this bigSurOffsetFix was implementing though because I can't replicate that on macOS 12.4
DetailWebView.setFrameSize() calls bigSurOffsetFix(), which changes the window's frame, which ultimately calls setFrameSize() again (which calls bigSurOffsetFix(), etc). In practice, this isn't causing an infinite loop (I think NSWindow.setFrame(_:display:) is smart enough to prevent reentrancy) but it's still dangerous to have such a glaring logic error in the code.
Move the code that twiddles the window frame from DetailWebView.viewDidEndLiveResize() into a new bigSurOffsetFix() API so it can also be called by setFrameSize() when the frame size is changed outside of a live resize.
Fix issue where detail web view would be overlapped by the toolbar in full screen by setting web view constraints to use the `safeAreaLayoutGuide` in macOS 11+.
Fix issue where detail web view would be overlapped by the toolbar in full screen by setting web view constraints to use the `safeAreaLayoutGuide` in macOS 11+.
