-
Notifications
You must be signed in to change notification settings - Fork 259
Fixes issues with plugins not loading in macOS Mojave (issue #668) #670
Fixes issues with plugins not loading in macOS Mojave (issue #668) #670
Conversation
Apparently Travis build if failing for reasons not concerning to this PR. Also, notice that I've been unable to test the fix in a previous macOS version, as I don't have any available. Maybe an improvement would be the workaround only being applied to Mojave, but more tests will be needed in previous OS versions to see if the forced User Agent causes any issue. |
Thanks for fixing this!
Radiant Player now builds, opens and plays music fine, but the UI is partly invisible (though still clickable): Did you encounter those problems, and if so, how did you solve them? |
Hi Tom. I'm a heavy user of Radiant Player, so I had to try to fix it! :) About the build, I basically opened the workspace in Xcode (as documentation states: Just be sure to open radiant-player-mac.xcworkspace instead of radiant-player-mac.xcodeproj in order to correctly pull in the dependencies into Xcode.), and the only change I needed to apply was to change the build system to the legacy one (I'm using Xcode 10). This is File -> Workspace Settings... -> set Build System to Legacy System. I understand that the dependencies in Gemfile are needed to build the website, so I didn't change anything nor didn't try to run it. Now you mention, I may try to fix this as well. About UI, I want to look at it as it also happened to me. My understanding is that this is due to new Xcode version toolchain changes (looks like Travis is trying to build using Xcode 7.1, while I'm already using Xcode 10). I wanted to create a separated PR for this. I'll check everything later and see what's the best way to proceed. Any suggestion? |
Okay i went ahead and had a look at this matter and with setting the custom useragent via You can test this for yourself with
my output was
so with just that out we can need en-force Radiant to "use" Safari in our agent as webkit blocks content with the Policy directive blocked-uri as there isn't Safari specified in the user agent so it will assume you never installed Flash So i put this to the test, i enabled dev tools in the native Safari app and removed Safari in the user agent and this is what i got So yup that's all it needs :) i would keep the current user agent and push in Safari and leave everything else default If you want you can test this yourself ;) (I however didn't get any error with Here is a test of the app built with my changes https://www.dropbox.com/s/ssnyufreplicxl5/Radiant%20Player%20%20Mojave%20Test.zip?dl=0
Happy coding! |
Thanks to @xrubioj for pointing the his solution This fix addresses the Blocked Plugin issue and UI properties are usable than a blanked out UI from @xrubioj original PR radiant-player#670 Legacy Build System is needed so i enabled it in my workspace Only if you set `UseModernBuildSystem=NO` in the Workspace setting ``` Xcode 9.3 adds a new IDEWorkspaceChecks.plist file to a workspace’s shared data, to store the state of necessary workspace checks. Committing this file to source control will prevent unnecessary rerunning of those checks for each user opening the workspace. ```
@BarakaAka1Only Works like a charm! Yesterday I used it the whole day. I haven't tested in a version prior to Mojave, but I guess there's no need as you wrapped the User Agent fix in a OS version check. About the CI failing to compile, I will try to fix it in my branch. Then we can integrate the changes in yours. Finally, about @tjanson comment on part of the UI not being shown, I did some tests last week, and it could be some kind of race condition: fails in debug build, but debugging and stopping seems to work. Maybe release builds don't expose the same behavior, as @BarakaAka1Only version is working. I'll probably investigate this further and try to do a separated PR if I find some solution. |
Nice, thank you for this! I'm going to go ahead and merge this change, and then we can open a followup PR to try to get the CI to build again. |
Thanks @jacobwgillespie In my opinion, though, I think @BarakaAka1Only PR #671 is better in the sense is more generic, and is safer (as is only targeting Mojave, which is the version we know is failing). About the CI build, I think I got it. It needs a manual step when compiling in Xcode 10.1 (or maybe because is Mojave), but should work in the CI. I'll commit the change later in a separated PR. |
BTW, @jacobwgillespie I've seen PR #672 and #673. Those are already addressing CI build, aren't it? My solution is more conservative, updating less gems. |
Yeah, it builds now without any build errors, but the resulting binary crashes immediately for me on Mojave, so something is still likely broken. |
Ah, maybe it's because of this:
I order to test, you have to go to System Preferences -> Privacy -> Accessibility and remove old Radiant Player. First time you run the build, you will get a dialog asking you to open System Preferences to give permission to the app. Then, you will have to run the app again. That being said, if that's the case for the final, release build, maybe a signature key or something like this has changed, as my understanding is that once you've given permission to the app, as far as the signature is the same, you should need to give it again. Update: works for me, after removing old Radiant Player in the System Settings, adding it again and running it again. I've tried it by downloading the package from GitHub releases and running it directly from Downloads folder, and also by updating it from the old app. In both cases I had to do the same drill, remove old app from Security Settings, adding it again and finally running the app again. Does this mean there's some kind of signature check? Or is something new from Mojave that need to be addressed? My guess is the later. Finally, my understanding is that the event tap is used to be able to react to media keys (maybe I'm wrong on this), and thus the app should not require it to work (but this implies changing the way this is initialized, etc.) |
@xrubioj Awesome to hear and happy that it is working 👍 @jacobwgillespie thanks for addressing the issue with travis |
@jacobwgillespie I've created issue #674 to keep the discussion. I'm already investigating alternatives in order to unregister the app automatically, or to re-register it reusing previous authorization. |
Workaround for the issue #668.
After some investigation, default user agent is apparently causing Google to serve different HTML. This causes an error (visible in the UI with two "Blocked Plug-In" labels at the bottom of the player). The internal reason is because some problem with Content Security Policy. Quoting the comment from kalkama:
Given that Safari should use WKWebView (which after some tests fails with the same error) I've concluded that changing the User Agent to simulate Safari could help, and indeed it does.
I've used the User Agent for Safari Version 12.0 (14606.1.36.1.9) running in macOS Mojave 10.14: