wakatime / macos-wakatime

Mac system tray app for automatic time tracking and metrics generated from your Xcode, Figma, Postman, etc. usage.
https://wakatime.com/mac
BSD 3-Clause "New" or "Revised" License
126 stars 22 forks source link

Support tracking Canva #250

Closed starbugs closed 3 months ago

starbugs commented 3 months ago

See my comment in the source.

Closes #236

alanhamlett commented 3 months ago

Nice workaround. We need to get element at position instead of walking the tree from the passed in element because they're different trees?

starbugs commented 3 months ago

Nice workaround. We need to get element at position instead of walking the tree from the passed in element because they're different trees?

Yes. As with many Electron apps, there's no WebArea node in the active window element's tree. But you can get access to element hierarchies by querying an element at a position. The same behavior can be reproduced in A11y Inspector.

One additional oddity of Canva is that the tab bar at the top of the window is not part of either tree. I don't know what they did there. I tried sampling the tabs by walking through x positions with a fixed y, but that only yields tab group elements that again don't expose any children.

On the flipside, this behavior is what makes the fix that I created quite workable. The active tab's web area root is properly titled and that seems to be consistent. So you always get the title of the current tab. Exactly what we need.

PS: I tried setting manual a11y on Canva and it fails with an error. So that solution for getting the whole tree exposed did not work here either.

I also checked all error conditions with this approach that I could think of. Window too small, window not visible at the time the check is made, etc. There may be edge cases in which a wrong title may be reported, but those should be extremely rare. You'd have to hide Canva and have another WebArea of a different app which is titled exactly at the same point on screen at exactly the right point in time. Maybe that's something we could guard against somehow, but that's the only condition that I could imagine where this reports something wrong. Otherwise, if anything fails, it should just report nil which should lead to no reporting at that point in time being sent to the API.