Permission callout shown even though permissions are granted #3801
Comments
|
|
|
Hi @wilky761, I can't reproduce this issue on my side. It is always happening for you, or just sometimes? Does it remain if you restart AltTab? When you restart your mac? Thank you 🙇 |
lwouis
changed the title
|
Hi there, thanks for the reply. It's only happened since upgrading to v7.1.1. I've tried restarting the app, and also rebooting my iMac, but I still have the issue......the app works by the way, no problem. I just have this incorrect message about permissions when I click on the app. 
|
|
I'm seeing the same warning on the latest version. I'm using Mac OS Monterey 12.7.6 |
|
You're both on macOS 12.7.6. It may be specific to that version. |
|
Could you please run this custom build from Terminal.app and share the logs here? |
|
macOS 13.7.1 has the same issue. |
|
V7.2.0 has not fixed it. I still have the "without screen recording permissions" message, and when I click on "grant permissions", the app crashes. |
|
Does it crash or does it just quit? If it crashes, you'll get asked to send a crash report on the next launch. Is it the case? If it is please send the report. Also could you please share this? Thank you |
|
Hi, I tried the custom build and open from terminal, still get the same issue.
|
|
These logs tell us that the fonction After the initial launch, and permissions are granted, AltTab will check if permissions are still granted, every 5s. If the permission is not granted, AltTab will restart. I'm surprised that AltTab is not restarting on your machine. I also don't see logs starting with Thank you |
|
I have the same problem in v7.2.0 in MacOS Ventura. The app works normally despite the warning: |
Hi, i tried the custom build again, there is no The full log is |
|
@houzixiashanxiedaima you need to grant Terminal.app the permissions, if you launch AltTab from the Terminal. I'm confused. You mentioned that you opened via the Terminal the previous time as well, yet that time, you said that the permission windows was all green, no? Thank you |
I apologize for the confusion. Let me be more specific:
|
Do you mean you see the permission window, or the callout in the menubar menu? Could you please share a video? Thank you |
|
Experiencing this too. AltTab 7.2.0, macOS Ventura 13.7.1, M1 MacBook Air. 
|
|
Could you please share a video? Thank you |
|
@lwouis I recorded a short 35s video, but unfortunately it's ~100MB, and GitHub won't allow anything bigger than 10MB. |
|
@lwouis Here's the video on YouTube. |
|
Thank you @michkozak! I can't find any clue. Looking at the code, it's a mystery: the same permission check is done to paint the background green as is done to display the purple callout. I can't imagine why it wouldn't be sync'd :/ |
|
Fortunately, unlike #3819, this one is only a UI bug, everything works as expected :). |
|
Have you tried removing the app from the permissions and readding it? Not just clicking the slider in the permissions window, but the "-" at the bottom. I recently had a permissions issue like that and doing that helped fix it. |
I tried this, but it didn't work. Thanks for the suggestion. |
|
For the record, I tried that many times too, didn't solve the problem. I even nuked the app and all its various related files and and reinstalled it - didn't solve the problem either. |
|
Just upgraded to v7.2.0 and ran into this as well. 
|
|
I'm on v7.3.0. and the issue is still happening..... |
|
Hi @wilky761, v7.3.0 has a new way to handle Mission control on macOS 12+. This should have fixed #3819. If I understand correctly, you suffer from the OP issue, which is that the permission is granted, yet AltTab shows the purple callout, correct? Could you please launch AltTab from Terminal.app as such?
Then could you please share the first 30s of logs? Thank you 🙇 |
|
~ % /Applications/AltTab.app/Contents/MacOS/AltTab --logs=debug |
Same for me I'm afraid. I also took a look at #3819, tried disabling the screen recording permission and checking the "Use the app without this permission" option, but the in-menu warning still shows when the app reopens. On a related note, the whole UI / UX regarding the interaction between this in-menu warning and that new option is a bit weird tbh. I'm guessing the warning isn't intended to show once we've checked the option, and obviously having checked it, AltTab's permissions checker dialog is no longer shown when the app starts up without screen recording permission. But even if the warning wasn't erroneously shown, it all just feels a bit circular somehow and I'm unsure what problem it's actually meant to solve. Ie. if a user has purposefully chosen to use without SR permission, no warning should be required anywhere. If we haven't specifically chosen this, the permissions checker should open because we haven't already checked the option. But in that case, surely the permissions checker window is launched automatically anyway, making the warning superfluous? Even if the user has purposefully skipped SR permission, it would still be convenient to have a shortcut to open the appropriate system settings tab somewhere within AltTab, in case we change our minds. I just find the big purple warning in the drop-down menu somewhat jarring, would it not be better suited as something less attention-grabbing within the preferences window? Off the top of my head maybe Appearance, maybe Policies, but I'm no semanticist 😅 |
|
@wilky761 when AltTab launches, it first checks for permissions. If they are not granted, it shows the PermissionsWindow. If they are granted, it launches silently. The logs you shared look like that initial permission check, before AltTab is launched. Did you see the permission window pop with all red permissions? When you launch AltTab from Terminal.app, you have to give Accessibility and Screen Recording permissions to Terminal, since it's the parent process. It seems here that you haven't done that. Could you please share a video of launching AltTab with the logs? Then we can see the full set of symptoms. Thank you 🙇 |
|
Hi @frypf, The purple callout exists so that people who check the checkbox to skip SR permissions know that they did, later on. It's easy for an impatient user to check that box to "get the app to work", and later on complain that the thumbnails are not showing. This callout reminds users that they run in a degraded mode, and can decide to upgrade by granting the missing permission. I understand that for users who know what they are doing, it's uncessary. However, we have to think of all users.
This is available by clicking on the menubar and picking Could you please share a video of the issue? With v7.3 released, I'm very surprised to see people still having the issue. I would like to see a video of the issue, with v7.3, so I can try and understand what's going on. Please run AltTab as indicated here, so we can get precious logs to try and debug the issue. Thank you 🙇 |
Almost as if to illustrate your point about users not reading things properly, I'd never actually noticed that menu item 🤦♂️😂 (although I'd never had cause to look for it until this issue came up). If, as you're saying, the callout is designed to be shown even if the user has specifically opted out of SR permission, it does still seem out of keeping with the rest of AltTabs well-considered UI. Anyway not my circus, and I'd likely never have had an opinion on it as I usually grant AltTab everything it asks for... we're all prone to occasional blind clicking to get stuff up-and-running faster I suppose. Screen.Recording.2024-11-11.at.17.54.07.mp4(I clicked the "Grant Permission" button at the end of the debug run). I did originally try to capture a log while I went through the same permissions toggling as in the video (ie. doing so for iTerm rather than AltTab itself), although when AltTab restarts itself due to permissions having been altered while running, it obviously just launches from the default location as its own process. |
|
Thank you @frypf. Unfortunately the video doesn't show the crutial sequence. Could you please show a video with these steps? We see AltTab launched, then running. Its permission window is shown with all green. It's menubar is clicked and shows purple. Thank you 🙇 |
Screen.Recording.2024-11-11.at.23.02.39.mp4 |
I feel like I'm missing something here. Wasn't the issue that the purple callout is still showing even when you grant the Screen Recording permissions? Not that it's still showing when you deny it, to act as a reminder. Unfortunately, the former still persists, even in the new v7.3.0. I can switch between granting and denying the Screen Recording permissions all day and no matter what I do — the purple callout is still showing 👍🏻. |
Yes @michkozak (and apologies @lwouis for polluting the issue scope / making you have to explain). Having never seen the callout or been aware of the option to deny SR permission prior to this issue, I wasn't clear on what the actual intended behaviour was. |
|
@frypf Thank you for the great video! indeed, we see the OP issue in your video. The permissions are correctly detected as granted. We see it clearly at 0:17. I boggles my mind how the callout can show. Yours logs show logger.d(accessibility, screenRecording, preStartupPermissionsPassed)
Menubar.permissionCalloutMenuItems?.forEach {
$0.isHidden = screenRecording != .skipped // here screenRecording is .granted, so this evaluates to true
}Could you please try out this build with additional logs? Could you please do the same steps as in the previous video and share the logs here? Thank you 🙇 |
|
|
Thank you @frypf This logs confirms that:
I'm at a loss now. Why is it that we set the callout to be hidden, and it works for most people, but somehow it fails to hide for a select few people? I don't know how to dig further. This looks like an AppKit bug. We ask AppKit to hide the element. If it's not hidden, what else can we do? I'm at a loss 😕 |
|
Yeah glancing over the logs and before I posted them, I figured the succession of Given you mentioned a potential AppKit bug, I guess this was in-part my gripe about the presence of the callout at all. It just looks a bit janky to my eyes and not something I would expect to see inside a menubar menu, although that's down to decisions on Apple's part rather than yours. |
|
From this StackOverflow thread, people seemed to have faced the same issue. I implemented the solution from their @frypf could you please try out this build and let me know if it fixes the issue for you? Thank you |
|
Yes that seems to have done the trick! 👍👏 I also tried revoking SR permission and checking the option to skip it, and the warning reappears as intended. I did notice that with the option checked, if I then click At that point if I either re-grant the SR permission within System Prefs or re-check AltTab also gets confused (either re-showing the warning or crashing upon shortcut, or both) if I check the option to skip while SR permission is already granted, or revoke the permission while the option is already checked, or generally when I toggle things out of the intended order. I sent all the crash reports I was presented with - feels like some sort of race condition in certain circumstances between checking granted vs skipped. By no means something that will affect day-to-day use, just thought you might want to be aware. Anyway, TL;DR: |
|
Thank you @frypf! I'll ship the fix in the next release, coming up soon. Could you please open a new ticket for the new issue? A video would really help here. The behavior seems tricky. Also, I can't find the any v7.3.0 crash report in AppCenter. I'm surprised since you said you sent them. Thank you 🙇 |
# [7.4.0](v7.3.0...v7.4.0) (2024-11-16) ### Bug Fixes * permission callout could show even with permission granted ([9585c92](9585c92)), closes [#3801](#3801) ### Features * better switcher max-width at various monitor sizes ([49178b5](49178b5)) * improve ar, de, el, hu, it, ko, pt localizations ([c4f98a1](c4f98a1))
|
7.4.0 resolved the issue for me, callout is no longer showing if I grant AltTab Screen Recording permissions. Thank you 🙏🏻. |
This issue was opened by a bot after a user submitted feedback through the in-app form.
From: paul_wilky76@icloud.com
Message:
Debug profile
The text was updated successfully, but these errors were encountered: