On Mac Codebook 3.1.4 (412), after upgrading to macOS Sierra 10.12.2 today, I can no longer use quick fill or, tab and press enter to enter a password from secret agent. Invariably, I get a “username or password is incorrect” type of error.
I can copy paste the password from Codebook into the website’s password box, without trouble.
This is happening in latest Safari, and Chrome 54.0.2840.98 (64-bit). I’ve got my keyboard switched to “US Standard” as you recommended in the other topic.
Thanks so much for the report. We noticed this yesterday as well. There appears to be a bug in the Sierra 10.12.2 update causing the apple script we use to enter mixed case improperly. Here’s a link to the open radar about it http://www.openradar.me/29182929 We were working on a fix yesterday and the updated version should be available shortly. In the mean time, unfortunately, the only workaround is to revert to copy/paste.
I’ll post back to this thread once the update is released to ensure it resolves the issue on your end as well.
Thanks again for taking the time, and sorry for the trouble.
Hi there,
I upgraded to 3.1.5 expecting this secret agent bug had gone, but it’s still there.
I’m using macOS Sierra 10.12.2 with “Italian” keyboard layout.
E.g. this is what I get from secret agent (double quotes are only for clarity):
The secret agent response is different every time.
Trying with US Standard keyboard layout changes the outcome, but remains wrong.
Cutting and pasting directly from Codebook still works fine.
Thanks for posting here, and sorry for the trouble. As I mentioned in my previous reply, there is a bug in macOS Sierra 10.12.2 causing the AppleScript we use to enter mixed case characters improperly (only after any character that would regularly require using the shift key – i.e the capital B in your first example or the @ symbol in your second two examples). We’re current beta testing a version that includes a fix for this issue. Would you be willing to try it out to ensure that it resolves the issue for you?
In addition, we made some modifications related to Secret Agent improperly entering values when using certain international key layouts – This is what was included in the 3.1.5 release. Unfortunately, because of the aforementioned bug (unrelated to this modification) Secret Agent is current improperly entering values.
Hi @mmoore@wgray - I tried the beta. After installing it, my version indicates 3.1.6 (418). After the install, it asks to upgrade a script and I say yes. Then I tested on:
The normal manual Secret Agent method works. The automated quick entry SA method works, but it did not work for me the first time, for some reason. I tried it immediately, it failed. I then used the manual method and it was fine, without any weird workarounds like having to copypaste.
Then, without restarting browsers, I tried logging out and logging back in on a site I always use, and the second time, the automated SA method was fine. Maybe there was something cached that was blocking it.
Thank so much for trying it out and confirming that the fix is working. We’ve been getting similar reports that the first time through it doesn’t always work, but subsequent times it seems to work fine (and resolves the issue). I’m also glad to hear you were able to install the beta this time around.
Sure thing @mmoore. I installed with some trepidation, but gladly the install just worked as expected.
But after a day away from Chrome, when I log in again via the quick entry macro I have for the site I usually have to log into, it does not work right. I can select the password alone, manually, in SA, but selecting the quick entry macro does not work.
Thanks for the follow up on this, and sorry to hear about the trouble re-appearing with Secret Agent Action/Quick Fill.
What happens when you select the quick entry macro? Does it not fill anything, or improperly fill the values (mixed case issue from Sierra)?
If you don’t mind sharing, what is the Macro you’re using (i.e. #[username]<tab>#[password]<enter>). Also does it only appear to be failing with one site and only in Chrome? Or all sites and across all browsers?
Would you mind trying to use the Secret Agent Action to fill into a text editor and let me know if the same result happens?
Thanks for posting and sorry for the trouble. We’re still beta testing the fix for this (although some users are reporting that Quick Fill isn’t consistently working, almost all users are reporting that regular passwords are filling properly). If you’d like to try it out, please pm me or write into support@zetetic.net and we’d be happy to provide you with it.
I am also having an issue after upgrading to 10.12.2. However, when I use Secret Agent to just place the password into a note, it puts it in exactly. When I try to put it into a password box on a piece of software I use, it does not. Any idea why it would be different if it was just a script error causing wrong cases for some letters?
Thanks for posting and sorry for the trouble. As I mentioned in an earlier reply, there is a bug that exists in the Sierra 10.12.2 update which causes the AppleScript we use for Secret Agent to improperly mix the case of characters after any character that would usually require using the shift key (i.e. the @ symbol or an uppercase letter). We’ve been beta testing a fix for this issue, and have gotten good feedback overall (although some users are still reporting that Secret Agent Action/Quick Fill doesn’t work consistently as you can see from this thread).
We’d be happy to provide you with the beta to try out, please PM me or write us at support@zetetic.net if you’re interested.
Just wanted to follow up on this. We’ve released Codebook for Mac 3.1.6 which includes the fix for this issue. We’ve still received reports of some users experiencing issues related to Secret Agent Action/Quick Fill, but we wanted to get the general fix released prior to the holiday break for App Store submissions. If anyone is still experiencing an issue with Secret Agent Action/ Quick Fill, please feel free to post here and outline the steps to reproduce, PM me, or write us at support@zetetic.net
Using Codebook Mac 3.1.6 (419), on the latest macOS Sierra, I’m still having trouble with SA actions on Safari. It seems to be working consistently in Chrome but, rarely in Safari.
Happy New Years! Thanks for the follow up on this. What happens when you attempt to enter data using a SA action in Safari? Does it improperly mix the case similar to the 10.12.2 bug? or does it not work at all? Does it only appear to be happening with certain websites? Certain SA actions? or all? If you don’t mind, could you share one SA action that isn’t working (i.e. #[username]<tab>#[password]<tab><space><enter><wait 1.3>#[totp]<enter> – that’s an example of one of mine that appears to be working in Safari). Could I also ask which model Mac you’re using (i.e. MacBook Pro (Retina, 15-inch, Mid 2015)) – I apologize if we’ve asked you that last one before but I couldn’t find it in your recent replies.
Ok, something specific I noticed. When I entered my GPG passphrase into GPG Keychain via SA, it strips the spaces out. I clicked “show typing” to check it, and noticed there are no spaces. If I simply copy-paste it, it is fine.
Codebook Version 3.2.1 (431)
macOS 10.12.3 (16D32)
Thanks for this report. We’ve been unable to reproduce this issue so far.
Here’s what I’ve tried:
Using SA and SAAction to enter password/plain text/number/email/pin/note types.
Switching the Language to Japanese and repeating 1.
Switching the Keyboard to US - International and repeating 1.
Entering mixed case characters and special characters before and after the spaces.
Ticked the “Automatically switch to a document’s input source” in the Keyboard preferences.
I have a few follow up questions to assist us in attempting to reproduce this locally:
Are there any other settings specific to your system that we could adjust on ours to try to reproduce this?
What is the “Mode” of the field you’re attempting to input (I’m assuming “Password”, and it should enter fine no matter the mode, but just want to try to mimic your setup as close as I can).
Does entering the same field into a text editor using SA enter the spaces properly?
Does the same thing occur when you try a very simple test passphrase, like “gpg passphrase”?
