WindowMizer Accessibility Bug

[rgbworld]

There is an issue with WindowMizer when updating from WindowMizer 4.3.1 or lower to WIndowMizer 4.4 or higher - including WindowMizer 5.x.

The problem is that when prompted to allow WindowMizer to use Accessibility features, pressing the "Open System Preferences" button takes you to System Preferences > Security & Privacy panel, but it is impossible to enable the checkbox next to WindowMizer.app.

macOS Sierra users note:
If you have upgraded to macOS 10.12.x prior to upgrading WindowMizer to version 4.4.x, then you will need to temporarily disable SIP, then run the patch, then re-enable SIP. Step-by-step instructions are here: https://www.rgbworld.com/forums/viewtop ... rt=20#p824. Note that you will still have to run the patch app below, but you have to do so while SIP is temporarily disabled. Please remember to re-enable SIP after applying the patch.

The Patch:
To fix the issue, please download this WindowMizerAccessibilityPatch.app. Unzip the file and run it by double-clicking the icon. You will need to enter your administrator password in order to apply the patch.

WindowMizerAccessibilityPatch.app.zip

(59.83 KiB) Downloaded 3619 times

This patch can be applied to version 4.3.1 to fix the checkbox issue or it can also be applied after the update to version 4.4.

Alternately, if you are comfortable using Terminal.app, you can copy/paste the code below into Terminal. You will need to enter your Administrator password in order to execute the command.

Code: Select all

sudo sqlite3 /Library/Application\ Support/com.apple.TCC/Tcc.db 'delete from access where client = "com.rgbworld.windowmizer"'

After running the patch or executing the terminal command, you should be able to launch WindowMizer and proceed to allow access by unlocking the Security & Privacy preference panel and enable the checkbox next to WindowMizer.

Thank you and sorry for the inconvenience. I am looking to for a way to apply the fix in a 4.4.1 update, but because the issue exists in previous versions of WindowMizer, this patch may be the only solution.

Chris

P.S. If the patch does not work, the only other suggestion I have for the moment is to try to Drag WindowMizer into the Security & Privacy panel even though it may already appear in the list. I will re-double my efforts to resolve this issue, but to date, the patch app is the best solution I have been able to devise.

[RonaldPR]

After updating to 4.4, I managed to launch WindowMizer after dragging its icon into the Accessibility Privacy panel.
This is on OSX 10.11.5.

But I now have another issue with WindowMizer 4.4 that did not exist with previous versions:

Normally, I can open a (new) window of an application that is running without window by single-clicking its icon it the Dock. However, with WindowMizer 4.4 running I need to double-click those icons to open a new window. Tested with Mail, Safari, TextEdit, and Finder.

[rgbworld]

After updating to 4.4, I managed to launch WindowMizer after dragging its icon into the Accessibility Privacy panel.
This is on OSX 10.11.5.

Dragging WindowMizer into the Accessibility panel has worked for myself and others. Thank you for your report.

Note: After dragging WindowMizer into the list, the checkbox still cannot be checked or unchecked. In all of my tests, the WindowMizerAccessibilityPatch.app available here viewtopic.php?f=5&t=26 has properly corrected the issue. After running the patch, the checkbox becomes functional and WindowMizer can be added/removed from the list as expected.

Normally, I can open a (new) window of an application that is running without window by single-clicking its icon it the Dock. However, with WindowMizer 4.4 running I need to double-click those icons to open a new window. Tested with Mail, Safari, TextEdit, and Finder.

Hmm. This creates an interesting dilemma that I will certainly review...
Many users suggested that when clicking the Dock icon of a specific application that all of the windows belonging to that application (including collapsed windows) should be brought to the foreground. I agree. The most commonly reported annoyance was that when clicking the dock icon of an application that either:
a) A new window would be created
b) The collapsed window would not come to the foreground

This is certainly an issue that I want to address, so as the 4.4 update settles in, I will concentrate on these fine details. Off the top of my head, I don't think I can have it both ways, so a WM preference setting may be required to provide alternative behaviors in this regard.

[rgbworld]

Update

I have tested the WindowMizerAccessibilityPatch.app on Mac OS 10.9 through 10.11.5 and the patch has successfully resolved the issue on every computer I have been able to test.

Some users have been able to get WindowMizer 4.4 running by simply dragging WindowMizer into the Privacy/Accessibility list, however with that solution, the checkbox still cannot be checked or unchecked and WindowMizer still cannot be removed from the list.

In contrast, the WindowMizerAccessibilityPatch.app (available above) properly corrects the issue. After running the patch, the checkbox becomes functional and WindowMizer can be added/removed from the list as expected.

Technical details of the underlying issue:
I am explaining the issue in detail in case another developer has a similar issue and so that users can understand what went wrong. As troublesome as GateKeeper and the newer Apple security measures may be, they are designed to keep our computing lives a little safer.

To my embarrassment, this issue is all about case-sensitivity. In all previous versions of WindowMizer, the bundle identifier for the application was "com.rgbworld.windowmizer" in all lower-case letters. With WindowMizer 4.4, the bundle identifier is "com.rgbworld.WindowMizer". The upper/lower-case version works with regard to enabling/disabling the checkbox and being able to remove the application from the Accessibility list. The easier solution would be to change the bundle identifier back to all lower-case letters, however this is what causes the non-functional checkbox, so I think it is best to fix it the right way. Unfortunately, it puts a little extra burden on the user and provides for a bad upgrade experience, for which I apologize.

What happened with previous versions of WindowMizer is that two nearly identical items were added to the database of application's allowed to use Accessibility features. It is the duplicate entry that is at the heart of this issue. Running this Terminal.app command lists all applications in the accessibility database. For WindowMizer, there were two entries: the all lower-case version, and the upper/lowercase version of the bundle identifier.

Code: Select all

sudo sqlite3 /Library/Application\ Support/com.apple.TCC/Tcc.db 'SELECT * FROM access'

This is what the list from the above Terminal command reveals showing the duplicate entry. After running the WindowMizerAccessibilityPatch.app, only the upper/lower-case version remains and it appears to resolve the issue.

TCC.db.png (11.96 KiB) Viewed 88373 times

Ideally, I would like to add the patch to the application, however, running the terminal command to fix the problem requires the user to enter an administrator password which complicates the issue. I would have to prompt for password to apply the patch, then open System Preferences allowing users to add WindowMizer to the Accessibility list – which also requires password input. It is pretty redundant.

Anyways, feedback is always welcome. I'll try to do a better job on the next update.

Thank you,
Chris

[BobbyCat]

OK, here's what I did.
Since I was blocked with the new 4.4, I decided to use AppZapper to erase everything, then used TimeMachine to get back to the previous version 4.3.1 from 2 days earlier. Worked well, and I was able to enter my activation code
Can't do without WindowMizer, so I'll just sit back with 4.3.1 and wait for another upgrade when it comes, no rush, thanks for trying to improve it

[jjh]

I've tried all three methods of resolving this issue with no luck, I still get prompted to Open System Preferences. I've tried the patch app, dragging the app into the panel, as well as the sqlite db queries. Is there a way of tracing what is happening?

OS X 10.10.5, what other details might be needed to help troubleshoot?

Code: Select all

$ sudo sqlite3 /Library/Application\ Support/com.apple.TCC/Tcc.db 'SELECT * FROM access'
Password:
kTCCServiceAccessibility|com.apple.Automator|0|1|1|
kTCCServiceAccessibility|com.rgbworld.WindowMizer|0|1|1|

Thanks for a wonderful product, I am dying to get it working again, I don't know how I lived without it.

[iamsammylou]

just wanted to say I was also having this issue, downloaded the patch today and it seems to have fixed the problem. thanks for your quick work and attention! love windowmizer

[rgbworld]

@jjh The best way to see what is happening is exactly as you did with that terminal command. In fact, what you show as a result is exactly as it should be as far as I understand the bits.

The working bits can be either of these 2 examples:

Code: Select all

kTCCServiceAccessibility|com.rgbworld.WindowMizer|0|1|1|??
kTCCServiceAccessibility|com.rgbworld.WindowMizer|0|1|1|

As far as I can determine, as long as there is not a lowercase version in the results, and there is only the upper/lower-case version, it should be fixed. This is a sample of non-working results given my hundreds of tests:

Code: Select all

kTCCServiceAccessibility|com.rgbworld.windowmizer|0|1|1|
kTCCServiceAccessibility|com.rgbworld.WindowMizer|0|0|1|

The patch removes the all lower-case version.

Have you restarted your computer after applying the patch?

[jjh]

@jjh
...
Have you restarted your computer after applying the patch?

I hadn't restarted the computer after applying the patch. WindowMizer is working again now, but it wasn't when I left my workstation on Friday. I know the sqlite db change is immediate, but does it have to propagate through the system somehow to other databases/plists?

Thanks for the great product, this is the only issue I've ever had with it after years of use.

[rgbworld]

@jjh On OS 10.10.5 and 10.11.5, the change was immediate. In fact I was able to keep the System Preferences window opened, and after running the patch, the checkbox was unchecked. Simply checking it again fixed the issue.

On OS 10.9.5 however, I got stuck in the loop. So I applied the patch, then restarted and I was able to then enable the checkbox and everything works.

For others that are still trying to resolve this issue, this is the only fix there is. I have tried it a hundred times now on 10 different computers and it has worked on every computer. I know it is a pain in the a$$ and I apologize, but it has to be fixed locally on your machine because the erroneous (nearly duplicate) entry is already in the database and the only way to remove it is with the patch app or the terminal command.

Also, just as a footnote, I don't add/remove items from the accessibility database. That is handled by the OS. My only mistake was having an all lower-case bundle identifier. Who would have known that it would cause this ugly mess-of-a-predicament :-/

For those reluctant to update, I understand. Please note however that the issue is not going to go away with version 4.4.1 (when it is released) because as stated, the bug is in previous versions of WindowMizer. The symptom can be seen in 4.3.1 by trying to enable or disable the checkbox in Accessibility list. If the checkbox does not check and uncheck as it should, then the patch needs to be applied.