Level up your business security with free, on-demand training and certification. Explore 1Password Academy today →
CIBC autofill not working
A few weeks ago, CIBC changed their sign in process for web banking. It used to be a single page where it asked for your card number (this is your debit card number, not your credit card) and password. Now it is a two step process where the first page asks for your card number and the second page asks for your password. 1Password is getting confused and thinks that the Card Number field is a credit card entry field. As a result, it only offers suggests from my list of credit cards. It does not offer me the option of chosing the CIBC log in entry. This makes things a royal pain because I have to open up the 1Password App, search for the CIBC login entry, copy the card number, paste it and move on to the password page. At least on the password page 1Password recognizes it and offers me the CIBC log in entry. And, yes, I have added the new sign in page url to the CIBC log in entry page.
Auto-login without keyboard or mouse actions
Can 1Password be configured to log in to a website automatically when a login screen is presented? I know this can be done with the 1Password extension: “Select the login for that site, then select Open & Fill,” but I want the login to happen without requiring any user actions. I was able to do this with LastPass: when navigating to the login page for a site, all of the login actions were done automatically — without keyboard or mouse actions. Is this possible with 1Password?"1password quit unexpectedly" at every startup
Hi, Everytime I switch on my PC an error window is popping up with this message "1password quit unexpectedly". Everything works fine, and 1password is working as expected. How could I get rid of this annoying popup? My version is 1Password for Windows 8.11.20 (81120039), running on Win11 25H2 Thanks
Sticky icon remains on other pages
Hi, Looking for advice on how to solve this issue, tried with 1Password - Password Manager > Hide on this page. That didn't change anything sadly. Only one user has this problem with one webpage where the icon from a login field remains, even when viewing other pages on the same website. The icon remains when navigating to other pages, as if the field remains hidden in the background. A refresh of the page removes the "ghost icon". Seems quite similar to another thread I found. https://www.1password.community/discussions/1password/1password-menu-icon-in-text-fields/36698
"Show in large type" unintuitively & dangerously goes to other display on desktop app.
I often make use of the "show in large type" feature as I find it convenient for certain settings. Sometimes I may be screen-sharing a single display in a multi-monitor setup, or perhaps I'm presenting something in-front of an audience. When doing this, I obviously wouldn't want 1Password on my shared display, I'd never deliberately show it. But I may still access it on my personal screen that isn't being shared. However, when clicking on "show in large type" in the desktop app (specifically tested with Windows in this case), 1Password will open a new window to display the large type view, and it will always display that window on the primary display, even if 1Password is not on the primary display. This has unironically caused me to accidentally leak a password in-front of an audience. Perhaps I shouldn't be touching my password manager whilst sharing my screen. But I would generally think it's okay to interact with the app whilst on a non-shared display, I wouldn't be thinking much of it and I imagine I'm not the only one. It would be great to ensure the large type view opens on the specific display that 1Password is open on to prevent situations like this from re-occurring. I also think it would be better UX regardless, I probably don't want a new view going to a completely different screen after clicking on something. This wouldn't happen on the browser extension for instance.Managed Update of Intune Win32 App
I deploy 1Password via Intune, and I recently transitioned our deployment from the MSI installer to the MSIX installer—as a Win32 app in both cases. I prefer to manage the deployed version and so disable Auto Update. When deploying using the MSI installer, I used a File detection rule that checked for the presence of the app and also checked the version. Rule type: File Path: C:\Program Files\1Password\app\8 File or folder: 1Password.exe Detection method: String (version) Operator: Greater than or equal to Value: 8.x.x Associated with a 32-bit app on 64-bit clients: No With this process, when I updated the installer version, I would update the version value in the detection rule, and Intune would update the installed version of 1Password when it detected a version number less than the expected value. Because the detection script provided for the MSIX deployment—AppDetectScript.ps1—does not include a version check, updating the installer version has no effect on devices where 1Password is already installed. Intune will report that the latest version is installed, but that is only because it is finding 1Password, not because it is finding the latest version of 1Password. I modified the script to include a version check, in hopes that that Intune would then behave as it had with the MSI installer, installing the latest version of the app when it detected that the installed version did not match the target version. # Modify the $targetVersion to ensure app updates $targetVersion = "8.12.10" $targetVersion = [Version] $targetVersion.ToString() # The unique 1Password identifier in detection scripts. $targetPackageFamilyName = "Agilebits.1Password_amwd9z03whsfe" try { # Per-user install (eg. Install behavior in Intune is User). $package = Get-AppxPackage | Where-Object { $_.PackageFamilyName -eq $targetPackageFamilyName } if ($package) { $ver = [Version] $package.Version.ToString() Write-Host "1Password is installed." if ($ver -ge $targetVersion) { Write-Host "1Password is up to date." exit 0 } else { Write-Host "1Password requires an update." exit 1 } } else { Write-Host "A 1Password installation wasn't found." exit 1 } } catch { Write-Host "An error occurred when detecting a 1Password installation: $_" exit 1 } As far as I can tell, the detection script worked, in the sense that it started registering the app as not installed—"The application was not detected after installation completed successfully"—but it did not cause the installed version to be updated. I know that the https://support.1password.com/deploy-1password/?windows#step-1-plan-your-deployment-windows states: To allow your team members to update 1Password, deploy the MSIX as a Win32 app and set the install behavior to User. To manage and deploy updates to 1Password, deploy the MSIX as a line-of-business app and set the install behavior to User. But all of our other Intune app deployments are Win32 apps, and, https://learn.microsoft.com/en-us/intune/intune-service/apps/apps-win32-troubleshoot#:~:text=If%20you%20mix%20the%20installation%20of%20Win32%20apps%20and%20line%2Dof%2Dbusiness%20(LOB)%20apps%20during%20Windows%20Autopilot%20enrollment%2C%20the%20app%20installation%20might%20fail., Win32 and LOB apps do not mix well when using Windows Autopilot (which we do): If you mix the installation of Win32 apps and line-of-business (LOB) apps during Windows Autopilot enrollment, the app installation might fail. I was hoping it might just work. Since it seems as though that is not the case, I was wondering if there is a technical reason why the MSIX deployment does not work as the MSI deployment did, if there is a chance that modifying the detection script in some way could work, and, given the answers to the first two questions, if there is some way this setup might be made to work in the future?
