How do I disable form autosubmit?
Comments
-
Thank you @PeterG_1P . Just to clarify: My preference -- to be able to globally disable autosubmit -- seems to be what everyone in this thread is asking for, except @bcometa who apparently likes autosubmit and wants to disable it only when it breaks the login process.
I'm with Michael Fey, who said in his previously referenced blog post, "We feel strongly that removing the ability to automatically submit passwords is the right call."
But I'd be happy with a setting to globally disable it.
0 -
My guess is that many, or even most, of the people posting in this thread are using Safari. After doing some digging, it looks like this is a combination of a few different issues.
- As discussed in this thread, for some reason part of the Safari extension often doesn't get registered correctly in the system. Anecdotally, it often seems to un-register during a browsing session, requiring me to run
lsregister -f -R /Applications/Safari.app
or sometimes evenlsregister -f -R /Applications/1Password\ for\ Safari.app
even when it worked just moments earlier. - The keyboard shortcuts for the new Safari extension are not currently configurable. As such, it responds to
Cmd+Shift+X
and notCmd+\
. - 1Password's new global autofill functionality likes to be helpful. As a result, pressing
Cmd+\
is caught by 1Password and the global autofill kicks in.
To break it down further, something along these lines is happening:
- User presses
Cmd+\
- 1Password app intercepts the shortcut
- 1Password app determines that the active app is Safari, identifies active site
- User selects which login item to use
- (Unconfirmed speculation on my part) 1Password app attempts to communicate this with Safari extension, but fails
- 1Password app, falling back to global autofill, injects keystrokes of the username, tab, the password, and return
0 - As discussed in this thread, for some reason part of the Safari extension often doesn't get registered correctly in the system. Anecdotally, it often seems to un-register during a browsing session, requiring me to run
-
Adding another +1 to this (both the option to globally disable as well as a by-item option)
0 -
This content has been removed.
-
I have done some more digging and believe the issue is that the 1Password desktop app does not attempt to communicate with the Safari extension if the user has pressed
Cmd+\
.Using Chrome
When I initiate autofill by clicking on the 1Password icon in the text box, the following is logged:
==> ./BrowserHelper/1Password_rCURRENT.log <== INFO 2022-05-12T16:51:46.457 ThreadId(55) [swift] XPCServer.swift:256 :: sendToMain(_:reply:) | Sending message to Desktop app INFO 2022-05-12T16:51:46.458 ThreadId(55) [swift] XPCServer.swift:265 :: broadcastToExtensions(_:) | Sending message to extensions
- The Chrome extension sends a message to the browser helper
- The browser helper relays the message to the desktop app
- The desktop app identifies the login to use, and sends the credentials to the browser helper
- The browser helper relays the message to the Chrome extension
- The Chrome extension fills the login form
When I initiate autofill using
Cmd+\
, the following is logged:==> ./1Password_rCURRENT.log <== INFO 2022-05-12T16:53:20.841 tokio-runtime-worker(ThreadId(50)) [swift] Brain.swift:475 :: collectPageDetails(fastCollection:prettyPrint:) | @Autofill: Collecting from pid(39035) INFO 2022-05-12T16:53:20.894 tokio-runtime-worker(ThreadId(50)) [swift] Brain.swift:369 :: collectTerminalElement(app:) | @Autofill: Active app isn't terminal, can't collect terminal element INFO 2022-05-12T16:53:20.898 tokio-runtime-worker(ThreadId(50)) [swift] Brain.swift:475 :: collectPageDetails(fastCollection:prettyPrint:) | @Autofill: Collecting from pid(39035) INFO 2022-05-12T16:53:20.938 tokio-runtime-worker(ThreadId(50)) [swift] Brain.swift:369 :: collectTerminalElement(app:) | @Autofill: Active app isn't terminal, can't collect terminal element ==> ./BrowserHelper/1Password_rCURRENT.log <== INFO 2022-05-12T16:53:20.940 ThreadId(55) [swift] XPCServer.swift:265 :: broadcastToExtensions(_:) | Sending message to extensions INFO 2022-05-12T16:53:20.955 ThreadId(55) [swift] XPCServer.swift:256 :: sendToMain(_:reply:) | Sending message to Desktop app ==> ./1Password_rCURRENT.log <== INFO 2022-05-12T16:53:20.970 tokio-runtime-worker(ThreadId(12)) [1P:op-app/src/app/backend/autofill.rs:494] Filled via b5x ==> ./BrowserHelper/1Password_rCURRENT.log <== INFO 2022-05-12T16:53:20.970 ThreadId(55) [swift] XPCServer.swift:265 :: broadcastToExtensions(_:) | Sending message to extensions
- The desktop app identifies the active app as a browser
- The desktop app sends a message to the browser helper requesting information on the active page
- The browser helper relays the message to the Chrome extension
- The Chrome extension provides information on the active page to the browser helper
- The browser helper relays the message to the desktop app
- The desktop app identifies the login to use, and sends the credentials to the browser helper
- The browser helper relays the message to the Chrome extension
- The Chrome extension fills the login form
Using Safari
When I initiate autofill by clicking on the 1Password icon in the text box, the following is logged:
==> ./BrowserHelper/1Password_rCURRENT.log <== INFO 2022-05-12T16:57:32.674 ThreadId(56) [swift] XPCServer.swift:256 :: sendToMain(_:reply:) | Sending message to Desktop app INFO 2022-05-12T16:57:32.674 ThreadId(56) [swift] XPCServer.swift:265 :: broadcastToExtensions(_:) | Sending message to extensions
- The Safari extension sends a message to the browser helper
- The browser helper relays the message to the desktop app
- The desktop app identifies the login to use, and sends the credentials to the browser helper
- The browser helper relays the message to the Safari extension
- The Safari extension fills the login form
When I initiate autofill using
Cmd+\
, the following is logged:=> ./1Password_rCURRENT.log <== INFO 2022-05-12T16:58:26.653 tokio-runtime-worker(ThreadId(51)) [swift] Brain.swift:475 :: collectPageDetails(fastCollection:prettyPrint:) | @Autofill: Collecting from pid(92041) INFO 2022-05-12T16:58:26.689 tokio-runtime-worker(ThreadId(51)) [swift] Brain.swift:369 :: collectTerminalElement(app:) | @Autofill: Active app isn't terminal, can't collect terminal element INFO 2022-05-12T16:58:26.692 tokio-runtime-worker(ThreadId(51)) [swift] Brain.swift:475 :: collectPageDetails(fastCollection:prettyPrint:) | @Autofill: Collecting from pid(92041) INFO 2022-05-12T16:58:26.701 tokio-runtime-worker(ThreadId(51)) [swift] Brain.swift:369 :: collectTerminalElement(app:) | @Autofill: Active app isn't terminal, can't collect terminal element INFO 2022-05-12T16:58:27.006 tokio-runtime-worker(ThreadId(51)) [swift] Brain.swift:475 :: collectPageDetails(fastCollection:prettyPrint:) | @Autofill: Collecting from pid(92041) INFO 2022-05-12T16:58:27.019 tokio-runtime-worker(ThreadId(51)) [swift] Brain.swift:369 :: collectTerminalElement(app:) | @Autofill: Active app isn't terminal, can't collect terminal element INFO 2022-05-12T16:58:27.020 tokio-runtime-worker(ThreadId(51)) [swift] Brain.swift:475 :: collectPageDetails(fastCollection:prettyPrint:) | @Autofill: Collecting from pid(92041) INFO 2022-05-12T16:58:27.039 tokio-runtime-worker(ThreadId(51)) [swift] Brain.swift:369 :: collectTerminalElement(app:) | @Autofill: Active app isn't terminal, can't collect terminal element INFO 2022-05-12T16:58:27.043 tokio-runtime-worker(ThreadId(14)) [1P:op-desktop-autofill/src/macos.rs:91] Filling designations: [username, current-password] INFO 2022-05-12T16:58:27.043 tokio-runtime-worker(ThreadId(51)) [swift] Brain.swift:566 :: executeFillScript(data:) | @Autofill: Executing fill script INFO 2022-05-12T16:58:27.044 tokio-runtime-worker(ThreadId(51)) [swift] Brain.swift:598 :: executeFillScript(data:) | @Autofill: Performing fill operation for frame 1 - OPID: Optional(0) INFO 2022-05-12T16:58:27.044 tokio-runtime-worker(ThreadId(51)) [swift] Brain.swift:607 :: executeFillScript(data:) | @Autofill: getting collected element for operation INFO 2022-05-12T16:58:27.048 tokio-runtime-worker(ThreadId(51)) [swift] Brain.swift:625 :: executeFillScript(data:) | @Autofill: @Focus – Element successfully focused INFO 2022-05-12T16:58:27.049 tokio-runtime-worker(ThreadId(51)) [swift] Brain.swift:739 :: poll(fn:sleepFor:maxAttempts:) | @Autofill: @poll – complete in 1 attempts INFO 2022-05-12T16:58:27.160 tokio-runtime-worker(ThreadId(51)) [swift] Brain.swift:697 :: executeFillScript(data:) | @Autofill: @Fill – element successfully filled by smart-type INFO 2022-05-12T16:58:27.160 tokio-runtime-worker(ThreadId(51)) [swift] Brain.swift:739 :: poll(fn:sleepFor:maxAttempts:) | @Autofill: @poll – complete in 5 attempts INFO 2022-05-12T16:58:27.161 tokio-runtime-worker(ThreadId(51)) [swift] Brain.swift:598 :: executeFillScript(data:) | @Autofill: Performing fill operation for frame 1 - OPID: Optional(1) INFO 2022-05-12T16:58:27.161 tokio-runtime-worker(ThreadId(51)) [swift] Brain.swift:607 :: executeFillScript(data:) | @Autofill: getting collected element for operation INFO 2022-05-12T16:58:27.225 tokio-runtime-worker(ThreadId(51)) [swift] Brain.swift:625 :: executeFillScript(data:) | @Autofill: @Focus – Element successfully focused INFO 2022-05-12T16:58:27.225 tokio-runtime-worker(ThreadId(51)) [swift] Brain.swift:739 :: poll(fn:sleepFor:maxAttempts:) | @Autofill: @poll – complete in 1 attempts INFO 2022-05-12T16:58:27.453 tokio-runtime-worker(ThreadId(51)) [swift] Brain.swift:697 :: executeFillScript(data:) | @Autofill: @Fill – element successfully filled by smart-type INFO 2022-05-12T16:58:27.453 tokio-runtime-worker(ThreadId(51)) [swift] Brain.swift:739 :: poll(fn:sleepFor:maxAttempts:) | @Autofill: @poll – complete in 21 attempts INFO 2022-05-12T16:58:27.557 tokio-runtime-worker(ThreadId(51)) [swift] Brain.swift:724 :: executeFillScript(data:) | @Autofill: typing enter INFO 2022-05-12T16:58:27.558 tokio-runtime-worker(ThreadId(51)) [swift] Brain.swift:475 :: collectPageDetails(fastCollection:prettyPrint:) | @Autofill: Collecting from pid(92041) INFO 2022-05-12T16:58:27.604 tokio-runtime-worker(ThreadId(51)) [swift] Brain.swift:369 :: collectTerminalElement(app:) | @Autofill: Active app isn't terminal, can't collect terminal element INFO 2022-05-12T16:58:27.607 tokio-runtime-worker(ThreadId(1)) [1P:op-desktop-autofill/src/macos.rs:117] Done filling
- The desktop app does not identify the active app as a browser
- Universal Autofill is invoked
- Using the accessibility API, the desktop app determines the active site
- The desktop app identifies the login to use
- Using the accessibility API, the desktop app injects credentials as keystroke events
Conclusion
1Password 8's detection of the active application does not appears to be correctly identifying that Safari is a browser and, as a result, is not even attempting to communicate with the Safari extension.
0 -
I cannot stress enough that this is probably the thing most in need of fixing right now. The fact that 1Password 8 is incorrectly falling back to Universal Autofill in Safari instead of filling through the browser extension is the cause behind many other usability issues that people are currently complaining about.
0 -
Hi @elyscape! Thank you so much for taking the time to dive in and write up the wonderful information above about Universal Autofill and the Safari extension. I really do appreciate you taking the time to do that. We're all super passionate about the product here and it's cool to see 😄.
I'm one of the developers who's worked on both the (new) 1Password extension for Safari and Universal Autofill, so I'd like to offer a bit of insight on the information above.
As discussed in this thread, for some reason part of the Safari extension often doesn't get registered correctly in the system. Anecdotally, it often seems to un-register during a browsing session, requiring me to run lsregister -f -R /Applications/Safari.app or sometimes even lsregister -f -R /Applications/1Password\ for\ Safari.app even when it worked just moments earlier.
That's very interesting. We've definitely been seeing reports of this issue, but I haven't heard of the extension disappearing while actively browsing Safari. When this occurs does the extension disappear from the toolbar / Safari's list of extensions in Safari preferences?
The keyboard shortcuts for the new Safari extension are not currently configurable. As such, it responds to Cmd+Shift+X and not Cmd+.
Yes, this is currently a limitation in the Safari extension that we are hoping to be able to lift in the future. One thing to note here is that the web extension API doesn't allow setting CMD + \ as a shortcut, so that's not an option for the Safari extension.
1Password's new global autofill functionality likes to be helpful. As a result, pressing Cmd+\ is caught by 1Password and the global autofill kicks in.
💯, we're able to register CMD + \ as a shortcut from the desktop app and so that's where we decide between using macOS accessibility APIs to perform a fill or the browser extension (based on the context).
(Unconfirmed speculation on my part) 1Password app attempts to communicate this with Safari extension, but fails
Close! Safari is actually the one browser where we're explicitly not reaching out to the browser extension to perform fills right now, instead relying entirely on accessibility-based filling (when using CMD + \). This is due to some challenges we've had getting the Safari extension to quickly and reliably perform actions when requested by the desktop app. We're actively working on this issue and we hope to be able to use the Safari extension to perform fills when using CMD + \ in the future, just like every other browser.
In the meantime, filling via the browser extension can be quickly accessed via the in-page suggestions that appear underneath login fields, as well as the CMD + SHIFT + X shortcut to open the extension pop-up (from which you can autofill logins via the keyboard).
1Password app, falling back to global autofill, injects keystrokes of the username, tab, the password, and return
Correct, although I would add that we use a number of methods to obtain field focus, and tab is a fallback (not the first thing we try).
0 -
That's very interesting. We've definitely been seeing reports of this issue, but I haven't heard of the extension disappearing while actively browsing Safari. When this occurs does the extension disappear from the toolbar / Safari's list of extensions in Safari preferences?
The extension remains around, but the in-page autofill menu stops functioning.
Close! Safari is actually the one browser where we're explicitly not reaching out to the browser extension to perform fills right now, instead relying entirely on accessibility-based filling (when using CMD + ). This is due to some challenges we've had getting the Safari extension to quickly and reliably perform actions when requested by the desktop app. We're actively working on this issue and we hope to be able to use the Safari extension to perform fills when using CMD + \ in the future, just like every other browser.
Yeah, this is the conclusion I came to in my later posts. It's nice to have confirmation that this is, at least at present, intentional. Gently, I would like to suggest that the promotion of 1Password 8 to GA perhaps should have waited until this issue was resolved. At present, the user experience with Safari is significantly worse with 1Password 8 than with 1Password 7, and I suspect that the plurality of users on macOS use Safari as their browser.
I would strongly recommend some form of public acknowledgement of the state of things with Safari and that the UX is being actively worked on, either in a new thread or in the app or both. Absent this, newly-upgrading users will continue to be surprised by the seeming regressions in UX, and there is significant risk that they will write off 1Password 8, or even 1Password entirely, as a failure.
I appreciate that there are a lot of things at play, and indeed there was a lot of impressive work done for 1Password 8, not the least of which being the fact that it's a complete rewrite. That being said, the fact that it was launched on Mac with the system's default browser not having UX parity with either 1Password 7 or other browsers is somewhat troubling, and it's worth evaluating why that decision was made.
0 -
Dropping another +1 for the ability to disable auto-submit, for all the reasons everyone has already mentioned. :D
0 -
It's really bad that it auto submits. Sometimes it fills in the wrong fields (the signup fields for example) and auto submits it.
Also pretty weird that during 1P7 you guys said yourself that autosubmit is something that is not desired and should be removed.
Why is it now the only option?
I guess it has something to do with the new universal codebase because you got it working great in previous versions...0 -
This content has been removed.
-
+1 for the ability to disable autosubmit, for all the reasons above. As a longtime 1Password user, I have years of muscle memory of Cmd + \ followed by the return key. Now that 1Password autosubmits, when I inadvertently hit return after Cmd + \, it seems to conflict with the timing of the autofill function and I often get a login failure.
0 -
+1
I was super excited for universal access for some of my desktop apps that use secured passwords, but some of my desktop apps should just have the password auto filled without auto submitting it. Since I can't disable this function (especially after I had to get used to it not auto submitting in my browser!), my main desktop app still requires me to manually go to 1Password to copy it.IMHO, for an MVP, have a feature flag to blanket toggle. Post-release, it would be lovely to still have a blanket toggle for those that want that, but also the ability to say "Don't auto submit for this specific app" would be my best case scenario.
This way I can get the auto submit in the browser and other places where it's applicable, but not have it where it shouldn't submit. Alternatively, an option to not auto submit a specific password would work too.Thanks 1Password team for all your efforts! It was clear that a lot went into 1Password 8 and much of it was driven by product feedback, including us complaining about the auto submit removal. With 1Password's expanded usability, it's understandable that some new features may not perfectly align with consumer's needs. It's clear you've heard us about this too, so thanks!
If you need a beta test, you've got one here that will happily give feedback.
0 -
+1 to restoring this ability to globally disable auto-submit.
Just echoing above, but I depend on 1Password not auto-submitting for a number of sites, for example a site that requires an OTP to be appended to the password that is entered, or one that takes the OTP at the same time as the password but 1Password fails to autofill it, or ... These now become very manual copy paste interactions between me and the site.
0 -
I'd like the ability to turn autosubmit off or on by website, like before but absent that ability to turn it off for all. I generally like it submitting but I have a few I use, e.g., Etrade, with dual factor turned on, and that requires me to add the one-time password manually after 1password autofills the password line, i.e., it's the password+one-time code, right in the password field. This version simply won't work with websites like that. It almost locked me out. What I have to do now is manually open site, manyally copy over user name, manually copy over password, then I enter the one-time password and click submit.
0 -
+1
0 -
Just updated to V8. I can see now that credentials filled via the safari extension are being auto submitted again. I understood that auto submit was removed years ago so I am surprised to see it is back.
I have a site that I need to manually enter parts of a second password, which I would normally do after auto filling then manually submit. How can I set autosubmit to never on this item?
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided0 -
So, auto-submit was disabled partly as a security feature in 7.2 and now it is forcibly enabled? This means in the right circumstances, 1Password 8 is now insecure (for example, 1Password fills in the wrong fields with your data, which is then sent to the server and stored in a log file). Had I known 1Password 8 was still in Alpha, I would not have tried it out. Now up to 4 pretty significant bugs which have all been forwarded to 1Password. 5 bugs if. you include the fact that this is an electron app and not a native app. The only thing holding me to 1Password right now is its ubiquity.
0 -
Ah, I was just coming here to post about this and saw this from earlier this morning. Yes!, Pease, please, please allow us to turn auto-submit off. It's driving me mad. There are just too many cases where I want to do something after auto-filling:
I tend to fire auto-fill pretty quickly after loading a page, often before I notice there's a "stay logged in" checkbox that I want to turned on. With auto-submit, I miss the opportunity to toggle it, which means I have to log in again next time I go to the site/app, at which point I repeat the cycle. It's vicious -- takes me a dozen-plus tries to break it sometimes. (Yes, I'm very dense. Or really, just very routine-driven.)
I have multiple logins for many things, many logins for a few. As a result, I sometimes choose the wrong one. Up through v7, this wasn't a big deal - I would simply look to see which account got filled and redo it if necessary. Now, I'm slammed into the account whether it's the right one or not, which means I have to wait for the site/app to load, find the logout function and click it, then try it all again. And in some cases (especially when SSO is being used), switching accounts doesn't always work reliably, which means it might take a few tries or even force clearing cookies or switching browsers. And with direct support for contexts outside the browser, there are all new unintended consequences that can happen, like downloading content to the machine with Dropbox or similar, accidentally purchasing an app with the wrong account in the App Store (thus locking it to the wrong account), or accidentally saving a file to the wrong account (MS Office). And some of those unintended consequences can have further consequences with one's employer, compliance, etc.
Some sites have secondary controls that appear as you're going through the login process; this is the OP's point. Sometimes, these are on the first page and visible right off the bat, which means I can deal with them if I'm not moving too quickly (see first item above). However, at other times, they only become visible once you fill in the username portion, or worse, they're only visible on the second or third page of a multi-step login process. In these cases, the only thing I can do is go back to my mid-'90s pre-password manager days and copy/paste the credential.
0 -
Hi @N33EKe3KWQJcpGdqLFh6, thanks for raising this concern.
So, auto-submit was disabled partly as a security feature in 7.2 and now it is forcibly enabled?
Auto-submit wasn't removed for any security-related reasons. At the time it was based on considerations around usability and the reliability of the experience.
However, I can understand where this might have come from. We have discussed auto-fill options and potential security risks around those in the past, but those potential behaviors diverge from how Quick Access acts.
This is from a blog that our security specialist Goldberg wrote a while back:
Automatically filling a web form with no user intervention other than visiting the page can, if combined with something that works around the anti-phishing mechanism [of 1Password], lead to an attack where lots your usernames and passwords are submitted to a malicious site in a way that is silent and invisible to you.
There are some important considerations here. The original discussion pertained to auto-fill that would be triggered by nothing other than visiting a web page. In the case of Quick Access, you have to tell it to fill. This is the difference between "manual auto-fill" (what Quick Access does) and "automatic auto-fill" (which we are not doing).
Secondly, 1Password's anti-phishing protection offers an additional important measure of security that's worth noting. 1Password won't fill your credentials from
domain A
intodomain B
, even if you manually invoke autofill functionality on that site. It has to match the domain you've assigned to the item (although, like in all aspects of security, nothing is bulletproof and our engineers have designed other aspects of 1Password to provide protection in case a malicious website is somehow able to get around this particular defense measure).We're happy to receive feedback on Quick Access, and whether our current approach is the right one, but I did want to specify that we aren't reversing any previous security design principles or going back on prior reasoning with this feature. 👍
For additional context, I'd highly suggest checking out Goldberg's 2017 blog post in full here, which is, characteristically, an edifying read.
0 -
Hi @PeterG_1P, I wonder if the mention that @N33EKe3KWQJcpGdqLFh6 is noting is from this link:
https://blog.1password.com/1password-7.2-for-mac-welcome-to-the-dark-side/#mojave-mo-secureI don't exactly read that as stating that the removal was for security, but it does seem a reasonable interference from the title of the section (Mojave, mo’ secure) and previous material.
That is the same section that notes:
You’ll also notice that 1Password 7.2 no longer automatically submits passwords once they have been filled. This was a difficult decision to make, but we made it for a few reasons that we wanted to share:
...
We feel strongly that removing the ability to automatically submit passwords is the right call. I’ll be fully transparent, it’s taken some getting used to, but now that it’s part of my workflow… autosubmit? I don’t miss it.
Personally I agree with that, please at least restore this as a user configurable option! The current behavior is pretty broken for many sites I use.
0 -
1Password 8 will happily auto fill the wrong credentials on subdomains. Which “may” not be a security issue but it sure is annoying. On Wordpress sites auto submit occurs with empty 2FA fields. @PeterG_1P , can you guarantee that 1Password will NEVER accidentally put login information into the wrong fields?
Mostly annoying though is that you are dictating how 1Password works for individual users. You had settings that allowed each user to choose what to do, and you have chosen to remove that choice for users. Pretty I am not alone on this. Sadly 1Password team seems to be sitting on their laurels now that they have market share. This is disappointing, as gone are the days when you listen to your users. 😕
Looking at your own blog, let’s focus on the auto submit portion:
Sometimes a website doesn’t behave as 1Password might expect, resulting in passwords being filled sub-optimally, or fields being left blank. If 1Password were to automatically submit forms in these cases, users are left with an experience that we don’t feel reflects how we want 1Password to work and can lead to confusion.
This hasn’t changed, it is still the case, why has your team deemed your own sales pitch, and this valid issue, now invalid?
@PeterG_1P since you are appearing to deflect by comparing auto fill with auto submit, let me quote the article:
If you are using a password manager that doesn’t allow you to turn that feature off, switch password managers.
This to me, and I suspect to all your users, could apply to auto submit as well.
Any developer worth his salt, knows when to say “we screwed up.” Maybe time for your team to consider this? Forcing auto submit is only one small issue with 1Password 8.
Don’t get me wrong, which is probably easy to do with my rant style here, I do think 1Password could one day be great again. But you need to take a step back and consider that just maybe, some of your decisions are wrong. You are not too big to fail.
Good luck!
0 -
I am very happy with auto-submit
But it would certainly re-assure some people if you make it optionalBut please do not remove it
0 -
Agree 100% with @Gilles9. The intent isn't to dictate how a user should use the app, but give them the option to use it how that want, within limits of course. Some users will want to use auto-submit which is fine. Freedom of choice and all that jazz. Which makes me think, could each login have an over ride. For example, if I set auto-submit to false globally, there might be some sites that auto-submit would be preferable on. Could I then enable auto-submit on those specific domains. Or perhaps the other way, global auto-submit is true and then opt out of auto-submit on a few troublesome sites?
I did just discover that using Firefox resolves many of these issues. Safari and 1Password appear to be the big issue here, where firefox doesn't have auto-submit, and 2FA works on sites that won't work in Safari. Hmm.
0 -
Count me in as one more user who wants a way to disable auto-submit.
I often hit Cmd+Backslash before realizing that I left a "remember me" checkbox unchecked.
0 -
+1 on being able to disable auto-submit. Went to sign into my lululemon account (on the UK site) and instead of logging me in it filled out the "sign up for our mailing list" box below the login form and submitted that. I note the US site doesn't have that same box in case you try it. It's basically useless if I can't trust it to fill out my details into the right place - will have to stick to 1Password 7 until then.
0 -
Another +1 for disabling autosubmit, globally across all passwords.
I won't be updating me or my family members to version 8 before this is possible.
I can't believe what I'm seeing, no explanation will suffice why this is not possible anymore in 8.
I will give it a few weeks before starting to look at other options for a password manager, but seeing how big 1Password has become, I fear we're not getting the feature back in years if ever... The personal touch and attention to detail we had with 1Password 10 years ago is long gone.
0 -
Hey @deeogo / @BobW / @mattmaker:
Thanks for your feedback on auto-submit. While I can't promise anything, I'll share your thoughts with the team.
In the meantime, if there's fields you need to edit after the fact (a second portion of the password for example), using the inline menu or the 1Password pop-up to autofill would be your best bet. Let me know how you get on with that!
Jack
ref: dev/core/core#14506
0