Alt-tab showing errors in system console launchd.log #2225
Comments
|
Hi, Looks like AltTab is trying to lookup some process in the OS called I'm not sure anything can be done. There is normal timeout to most retries in AltTab, so this shouldn't happen for a long period. It should probably also not impact your CPU much. You can check the Activity Monitor app to confirm AltTab's CPU usage. Closing this as I don't see what could possibly be done here. The OS is logging this, not AltTab. AltTab is listening to processes as an essential part of windows tracking. |
|
@burdo3417 are you using Firefox? For me the PID of the processes with The actual bundle ID for that app is It didn't seem to help when I tried to blacklist both I guess these are related #1481 #1484 (cc @metacodes) |
|
I was able to silence this by not starting diff --git a/src/logic/Application.swift b/src/logic/Application.swift
index 20733a3..56ba3b3 100644
--- a/src/logic/Application.swift
+++ b/src/logic/Application.swift
@@ -55,7 +55,9 @@ class Application: NSObject {
axUiElement = AXUIElementCreateApplication(pid)
AXObserverCreate(pid, axObserverCallback, &axObserver)
debugPrint("Adding app", pid ?? "nil", runningApplication.bundleIdentifier ?? "nil")
- observeEvents()
+ if (runningApplication.bundleIdentifier != "org.mozilla.plugincontainer") {
+ observeEvents()
+ }
}
}edit: I can still see the error sometimes, but now the PID being logged is no longer running unlike with |
|
I am using Firefox. Where do you make these changes? |
|
This function, then compiled a debug build in Xcode. Had to delete the existing permissions for AltTab to get the debug build working, probably because of code signing differences compared to the production build alt-tab-macos/src/logic/Application.swift Lines 53 to 60 in b57a39d |
The process has a PID every time it's retrying: Screen.Recording.2023-01-14.at.21.02.45.movEventually it stops retrying, because there is a timeout (2min). The reason we retry is because some process are spawned, and they won't let AltTab subscribe to their events right away. They may be showing the user a splash screen as they load lots of important infrastructure (e.g. Gimp, Photoshop). We have to retry until it works, as there is no other way to know when the app is ready. The Furthermore, the retries are only every 250ms, so it's really not going to make the CPU go crazy. I think the main issue here is that Firefox spawns multiple of these buggy We could blacklist that process since it's very specific to Firefox. Or Mozilla could fix it. That would work too. |
|
Blacklist it please! |
|
@lwouis Thank you for the reply!
Yes, you're seeing the same thing as me with plugincontainer, that's good to confirm. I agree that it makes sense to try again until the process responds as long as the process is running, but I'm not very familiar with macOS programming in general. Anyway, I was a bit unclear what I meant by my idea. I meant processes that are not plugincontainer but show up in the logs. However, after some testing this doesn't seem to be a problem. I ran the following script and was able to capture the name of the process that still caused com.apple.axserver logging after ignoring plugincontainer. What I expected to be a 2 minute log spam stopped as soon as it started. System Settings does not immediately reply to AltTab and I always quit it before checking the logs, so I initially expected that the logs came after terminating the process, which is not the case below: import psutil
import time
import datetime
procs = {}
while True:
ts = datetime.datetime.now().isoformat()
for proc in psutil.process_iter():
if proc.pid not in procs:
procs[proc.pid] = proc
print(ts, proc)
for proc in list(procs.values()):
if not proc.is_running():
print(ts, proc)
del procs[proc.pid]
time.sleep(0.5)I was personally more concerned about SSD durability than CPU usage when I found this, and was going through the entire file system to find files that are being written to constantly. I agree that 250 ms is a reasonable retry interval if the plugincontainer noise is silenced. To me blacklisting plugincontainer in AltTab seems like a reasonable fix for now, but Firefox devs would probably also be interested in fixing it at some point unless there is some security aspect in that these are sandboxed processes. I can try to report this if I manage to create a more simple POC. Should I turn my AltTab patch above into a PR? |
|
AltTab filters out processes to only listen to processes that could spawn windows. This In other words, this process is setup by Mozilla as a process that accessibility apps, such as AltTab, may want to monitor, as it could spawn windows at any time, and these accessibility apps would then need to know about those to assist the user. However, it seems that we can never subscribe to their accessibility events. This seems to indicate that either (a) they contain logic bugs that prevent them from being observed, or (b) that they shouldn't be flagged as In order words, Mozilla should fix those. I'm not a fan of complexifying AltTab's codebase with names of specific companies. However, it's been done before when we know the company will not step up and fix their issue.
No. It we integrate this, it should be done upstream. Before the |
|
I believe it's not just Firefox, it's actually Webkit(?) as well, or certain configurations that use this. Jetbrains toolbox triggers this, which uses webkit I believe (https://blog.jetbrains.com/kotlin/2021/12/compose-multiplatform-toolbox-case-study/). |
|
Looked into this again. Here's a minimal POC for the issue that I made by copying the relevant code in AltTab: // compile:
// swiftc filename.swift
import Cocoa
func axObserverCallback(observer: AXObserver, element: AXUIElement, notificationName: CFString, _: UnsafeMutableRawPointer?) -> Void {
/* print(observer, element, notificationName) */
}
let apps = NSWorkspace.shared.runningApplications
for app in apps {
let pid = app.processIdentifier
let axUiElement = AXUIElementCreateApplication(pid)
var axObserver: AXObserver? = nil
AXObserverCreate(pid, axObserverCallback, &axObserver)
AXObserverAddNotification(axObserver!, axUiElement, kAXFocusedWindowChangedNotification as CFString, nil)
print(app.activationPolicy.rawValue, app, axUiElement)
}Like you said @lwouis does this make sense? (I can also just create a PR) diff --git a/src/logic/Applications.swift b/src/logic/Applications.swift
index 80130da..d5df8b9 100644
--- a/src/logic/Applications.swift
+++ b/src/logic/Applications.swift
@@ -110,7 +110,7 @@ class Applications {
private static func isActualApplication(_ app: NSRunningApplication) -> Bool {
// an app can start with .activationPolicy == .prohibited, then transition to != .prohibited later
// an app can be both activationPolicy == .accessory and XPC (e.g. com.apple.dock.etci)
- return (isNotXpc(app) || isAndroidEmulator(app)) && !app.processIdentifier.isZombie()
+ return (isNotXpc(app) || isAndroidEmulator(app)) && !app.processIdentifier.isZombie() && !isInvalidActivationPolicy(app)
}
private static func isNotXpc(_ app: NSRunningApplication) -> Bool {
@@ -128,6 +128,12 @@ class Applications {
return app.processIdentifier != ProcessInfo.processInfo.processIdentifier
}
+ // these apps report their activationPolicy as accessory but do not support AXObserverAddNotification
+ private static func isInvalidActivationPolicy(_ app: NSRunningApplication) -> Bool {
+ let bundleId = app.bundleIdentifier
+ return app.activationPolicy == .accessory && bundleId == "org.mozilla.plugincontainer"
+ }
+
static func isAndroidEmulator(_ app: NSRunningApplication) -> Bool {
// NSRunningApplication provides no way to identify the emulator; we pattern match on its KERN_PROCARGS
if app.bundleIdentifier == nil,@joshuataylor I tried Jetbrains toolbox, and while I did get some log spam, it stopped as soon as the window became visible. It also happens to me with System Settings. |
As a special case, make Applications.isActualApplication return false for Firefox plugincontainer. github: fix lwouis#2225
As a special case, make Applications.isActualApplication return false for Firefox plugincontainer so that it is not observed with the accessibility API. These processes do not support AX observer notifications although they report activationPolicy=accessory. ref: https://developer.apple.com/documentation/appkit/nsapplication/activationpolicy/accessory github: fix lwouis#2225
|
That's wonderful that Mozilla fixed it, thank you @siikamiika. FYI, things like |
|
Thanks for the hard work @siikamiika. |
|
This also happens when System Preferences is closed, on MacOS Monterey 12.6.3 (21G419) as noted above. If you run the Python script above, you can reproduce this as follows:
|
|
I think the bug was fixed on Firefox v111. |
The same error it's shown in the console log every milisecond.
I'm not sure what is it.
I'm having a bit of high CPU usage, not sure if this is the cause.
The text was updated successfully, but these errors were encountered: