Codebook for macOS 4.5.2 is available now.
This release includes the bug fixes and improvements listed below:
- Adjusts Touch ID Login feature to prevent some edge case bugs
- Fixes display of rows in the Entries list on macOS 10.12 Sierra
- Fixes failure to capture some Note edits for Sync
- Includes a database adjustment for Fields with a missing created_at date
- Fixes Dropbox account email not displaying properly on Preferences Sync tab when first linking
- Fixes Unlink cloud service button not working on Preferences Sync tab when first linking
- Adds new preference for controlling clipboard behavior for double-click on Fields
- Updates layout and arrangement of settings on the General tab of the Preferences window
- Fixes several memory leaks (still working on a remaining issue with the system clipboard API)
- Fixes Copy 2-Step Code alert not dismissing when using Password AutoFill QuickType with remain unlocked setting enabled
- Updates SQLCipher to version 4.5.1
A few notes on some of these changes follow.
We are aware of customers occasionally running into an error when attempting Touch ID Login, with the error code
-25291, which stands for
errSecNotAvailable. This is a pretty difficult condition to reproduce, and seems specific to the device (the most recent customer support ticket for this ended when the problem went away on its own). Nevertheless, we found some places in our Touch ID Login code where unexpected or undefined behavior was possible and we’ve tightened all that up in this release.
We’ve tracked down a few different bugs that made it possible in some edge cases to make an edit to a Note that would then fail to transfer to other devices on sync. If you have any edits in this state, we can help you get those properly replicated to your other devices using the Merge operation during sync. Please get in touch if you’d like some help with that.
For a very long time now, Codebook for macOS has supported the ability to double-click on Fields in the Entry view. For Website and other “openable” field types (email, phone, URL), double-click launches the field in the appropriate app (e.g. opens the Website in your default browser). For all other field types, double-click would copy the value to the clipboard.
That last behavior was included at the request of many customers, who were used to double-clicking passwords to copy them in other password managers they were migrating from (KeePass in particular, if I recall correctly now). However, some customers have told us they do not wish to copy passwords to the clipboard at all, and find this behavior to be hidden and undesirable.
In this release we’ve included a preference to control that behavior. On by default (to reflect the current behavior), you can uncheck “Double-click on fields to copy to the clipboard” on the General pane of the Preferences window to turn it off. (We’ve also made some nice layout improvements to the General pane while we were in there.)
In a future release we may default this behavior to off. That would likely be alongside an improvement we’re working on to display all URL fields with a link control that’s single-clickable. We’re interested in any feedback you may have about these behaviors.
We’ve locked down the ones we have control over in our code. However, one remains. There appears to be a known problem with the clipboard API leaking that’s been around for some time. We’ve filed a TSI and a bug report with Apple, but a fix may not be coming soon. We’ll be working on potential mitigations in a future update.
There is a bug in the macOS support for Password AutoFill extensions that causes them to fail to draw or appear to go blank, sometimes. Not very often, but often enough to be annoying! This even occurs with Apple’s own sample AutoFill extension code. We’ve filed a bug report and are hopeful that it will get resolved in a coming macOS update, though we haven’t heard back yet–quite a few AutoFill bugs have been fixed recently in macOS. We’ll keep looking for ways around it in the meantime.
There’s also an issue with CPU utilization of the Codebook AutoFill extension process on macOS Monterey (Big Sur does not appear to be affected). We’re still working on this issue. It seems the latest versions of Monterey (public release and beta) have solved the problem of the process remaining in memory long after use, but the CPU utilization is still too high when the extension is in use. We’re continuing to work on this. UPDATE: This bug has been found and squashed; a fix for it will be included in the next update.
Finally, there was an issue with the new 2-Step Code copy behavior that we added to the AutoFill extension in version 4.5.0: sometimes the small view we presented confirming the copy (and how many seconds were left on the code) would not be dismissed with the extension, and remain stuck on the screen until quitting Safari. That’s fixed up in this version.