Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] Conflict with PowerPoint, can't add notes for a slide when Dock Exposé is running #23

Open
ftorelli165 opened this issue May 23, 2023 · 3 comments
Labels
bug Something isn't working

Comments

@ftorelli165
Copy link

ftorelli165 commented May 23, 2023

Permissions reset

Right click is now blocked by the preview window. It looks like it's attempting to open, stutters, but can't get it to open.

Steps to reproduce the bug

  1. Right click on open app

DockAltTab version: 2.8
macOS version: 13.2.1

I was able to reset all my permissions with your instructions, and it does appear to have solved this issue, but there's

another issue I noticed this morning in PowerPoint. I'll attach a screen recording where I'm trying to type notes into a PPT and you can see the mouse or focus is jumping around and I'm unable to actually select where I want to type in the notes section. When I turn dockalttab off it starts working again normally.
Screen Recording 2023-05-24 at 9.15.04 AM.zip

@steventheworker
Copy link
Owner

steventheworker commented May 24, 2023

Resetting permissions

I think your permissions are goofing. Here's how to reset them.

It would also be interesting to know if simply updating the OS can fix this, since personally this usually only ever happens to me after updating the OS, which makes me wonder if it can undo this ghost permission issue.

You can also try specifically resetting the "Input Monitoring" permission as that's the specific one that gives access to clicks.

Same bug as Dock Exposé #12

After taking a closer look, I think it's a PowerPoint bug, or less likely a macOS bug.

Explanation: It looks like any app using AXUIElementCopyElementAtPosition triggers some sort of update on PowerPoint, as well. Each time it is called PowerPoint appears to focus/unfocus the "Click to add notes" input, based on where the mouse is at the time...

This function is used to check if the mouse is under a AltTab preview / the dock / regular window. Seeing as it runs on each tick of the interval (which runs ~3 times a second), it would take a bit of a rewrite to fix...

I halved the calls specifically for PowerPoint in Dock Exposé, but iirc it was harder to remove those calls from DockAltTab. I can probably get them both to function as well as each other, but to feel seamless, would require a rewrite of both apps (which I am working on).

Report this to Microsoft (Help -> Feedback)

 

example message:

Using AXUIElementCopyElementAtPosition (on a different macOS objective-c app) triggers an update on PowerPoint, as well. Each time it is called PowerPoint appears to focus/unfocus the "Click to add notes" input, based on where the mouse is at the time... this prevents adding notes while a screenreader-like app is running (which call that function regularly).

https://github.com/steventheworker/DockAltTab/issues//23

@steventheworker steventheworker changed the title Right click on app icon not working [Bug] Conflict with PowerPoint, can't add notes for a slide when Dock Exposé is running May 24, 2023
Repository owner deleted a comment from ftorelli165 May 24, 2023
@steventheworker steventheworker added the bug Something isn't working label May 24, 2023
@steventheworker
Copy link
Owner

I'm sure now that I've worked on a rebuild of this project that it's a PowerPoint bug. I'm adding Ubuntu's preview behavior (you can find it under pre-releases (v2.91.0))... it circumvents this issue, since it only reads mouse locations on click.

I am working on a workaround for the regular previews too, just posting with a proposed solution:

...since I'm already listening to clicks, I can just check if the active app is powerpoint and store the mouselocation of clicks that happen only on the the tricky element/input. when the mouse leaves the input, I can simulate the last mousedown/mousemove/mouseup that happened in the textarea (after reading the location), and do so until the user clicks outside the tricky element.

I don't know if this will work. Will update.

@steventheworker
Copy link
Owner

v2.91.0 has Ubuntu mode now, and I've since thought of another way of solving this, so later on it's possible I can get a workaround working for hover previews too!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants