Unstable / Crashes with new MacOS Mojave #1490
Comments
|
Also experienced a few crashes after i update. But wasn't sure what the cause was. |
|
Yea I have tried a few ways, like pausing before going back and still the same... when I have time, which being a web developer at the moment don't have much for playing but will download source and see if I can debug but glad I am not the only person getting the issue as well. I am still using the application of course as it's a really good torrent app, nothing better in my opinion so i just wait for it to crash and then open it back up but thought should raise the bug anyhow. Was / and not sure if development is still going on with WebTorrent as had it installed around a year now which was version 0.20.0 and noticed that is still the latest release, hence why thought might have been out of date and checked out if was a new version but wasn't.... hence the raising of this bug lol |
|
Not sure if this helps, done a local build and when doing npm run watch this was the log |
|
The warning is mentioned in a bunch electron issues. It doesn't appear to have been completely fixed yet. However, this should not cause a crash. It would be helpful, if you could checkout the |
|
Will give it a try and let you know |
|
So switched to that branch, done a new npm install and then a npm run watch but same thing with crashing. Is there anyway to monitor in the console to try and catch it breaking? Below is what I am getting in the console after the crash, and also git status showing the branch: DetailsAdmins-MacBook-Pro:webtorrent-desktop james$ npm run watchwebtorrent-desktop@0.20.0 watch /Users/james/Websites/Clients/WebTorrent/webtorrent-desktop [nodemon] 1.14.11 webtorrent-desktop@0.20.0 start /Users/james/Websites/Clients/WebTorrent/webtorrent-desktop webtorrent-desktop@0.20.0 build /Users/james/Websites/Clients/WebTorrent/webtorrent-desktop 2018-10-05 02:03:17.005 Electron[23164:4306165] *** WARNING: Textured window <AtomNSWindow: 0x7f85c6409550> is getting an implicitly transparent titlebar. This will break when linking against newer SDKs. Use NSWindow's -titlebarAppearsTransparent=YES instead. Untracked files: nothing added to commit but untracked files present (use "git add" to track) And if helpful here is the crash report from my macbook: DetailsProcess: Electron [23230] Path: /Users/USER/*/Electron.app/Contents/MacOS/Electron Identifier: com.github.electron Version: 3.0.0 (3.0.0) Code Type: X86-64 (Native) Parent Process: node [23229] Responsible: Terminal [10387] User ID: 501Date/Time: 2018-10-05 02:09:28.942 +0100 Sleep/Wake UUID: 3B5970F2-D537-4673-A304-537A15157411 Time Awake Since Boot: 190000 seconds System Integrity Protection: enabled Crashed Thread: 0 CrBrowserMain Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_INSTRUCTION (SIGILL) Application Specific Information: Thread 0 Crashed:: CrBrowserMain Dispatch queue: com.apple.main-thread Thread 1: Thread 2: Thread 3: Thread 4: Thread 5: Thread 6: Thread 7: Thread 8: Thread 9: Thread 10: Thread 11: Thread 12:: Chrome_IOThread Thread 13:: NetworkConfigWatcher Thread 14:: DnsConfigService Thread 15:: CrShutdownDetector Thread 16:: TaskSchedulerServiceThread Thread 17:: TaskSchedulerBackgroundWorker Thread 18:: TaskSchedulerBackgroundBlockingWorker Thread 19:: TaskSchedulerForegroundWorker Thread 20:: TaskSchedulerForegroundBlockingWorker Thread 21:: TaskSchedulerForegroundBlockingWorker Thread 22:: TaskSchedulerForegroundBlockingWorker Thread 23:: TaskSchedulerSingleThreadForegroundBlocking0 Thread 24:: TaskSchedulerSingleThreadSharedBackgroundBlocking1 Thread 25:: CompositorTileWorker1/44035 Thread 26:: AudioThread Thread 27: Thread 28: Thread 29:: com.apple.NSEventThread Thread 30:: TaskSchedulerBackgroundBlockingWorker Thread 31:: NetworkConfigWatcher Thread 32:: TaskSchedulerBackgroundBlockingWorker Thread 33:: CacheThread_BlockFile Thread 34:: Dispatch queue: NSCGSDisableUpdates Thread 35:: TaskSchedulerForegroundBlockingWorker Thread 36:: TaskSchedulerForegroundBlockingWorker Thread 37:: TaskSchedulerForegroundBlockingWorker Thread 38:: TaskSchedulerForegroundBlockingWorker Thread 39:: TaskSchedulerForegroundBlockingWorker Thread 40:: PowerSaveBlocker Thread 41:: com.apple.audio.IOThread.client Thread 0 crashed with X86 Thread State (64-bit): Logical CPU: 4 Binary Images: External Modification Summary: VM Region Summary: REGION TYPE SIZE COUNT (non-coalesced) Model: MacBookPro11,3, BootROM MBP112.0146.B00, 4 processors, Intel Core i7, 2.3 GHz, 16 GB, SMC 2.19f12 |
|
Thanks for looking into this. I think this could be related to electron/electron#14837. |
|
Temporarily you can give Accessibility access for WebTorrent in your settings |
|
@MrDarkSkil I don't know much about Mojave, does the app have to request accessibility access before the user can allow it? And does that solve this issue? We could also temporarily disable media keys in Mojave. Hopefully, someone with Mojave can make a pull request. |
|
Now Mojave does as on the iPhone it asks the user when an application want to access to an system functionality, in this case with WebTorrent it asks to be able control the mac (for the management of keyboard keybinding i think), if the user refuse, electron can't register and unregister keyboard keybinding and produce an crash. So if you give WebTorrent the Accessibility access, electron can register a keyboard events and will not crash. |
|
@MrDarkSkil thanks a lot. Solved the problem for me. However I hope this can be fixed without giving the app these permissions. |
|
Confirmed I had the same issue as OP. To stop the crashing here's what I did:
|
|
This workaround (giving WebTorrent Accessibility permissions to prevent the crash) should be made clear in an FAQ or in a pop-up message within the app before making the call to request accessibility permissions and show the native OS dialog. Since the Accessibility permissions can be used to log keystrokes and do other nasty things, getting asked for these permissions from a torrent client without any kind of explanation is pretty sketch. I had to do some Googling to try to understand why WebTorrent was requesting this, which lead me here. Please make this more clear. If you are requesting elevated permissions from the user, always explain why you need them. |
|
I still see this crash every time when trying to play in-app, if OS X Accessibility controls denied. 😵 The upstream issue in electron appears fixed by electron/electron#16262, landed in PR to upgrade electron: #1523. |
|
I'm going to close this issue as the problem is fixed on |
What version of WebTorrent Desktop? (See the 'About WebTorrent' menu)
Version 0.20.0 (0.99.3)
What operating system and version?
MacOS Mojave (10.14)
What did you do?
When adding torrent it crashes, when clicking back to torrent list it also crashes
What did you expect to happen?
Not to crash
What actually happened?
It Crashed
The text was updated successfully, but these errors were encountered: