Disable “Auto-fill On Page Load” for specific logins

Feature name:

Disable “Auto-fill On Page Load” for specific logins

Feature Description

As requested in this feature request thread: Disable “Autofill On Page Load” option for specific logins.

This will add a checkbox on login items allowing the user to disable that login from auto-filling on page load. Suggested UI mockup:

This will also allow users to choose which item auto-fills on page load (by disabling all competing logins), as requested here: Autofill on Page Load for Specific Logins.

Clients / Repos Affected:

  • Server
  • jslib
  • Browser
  • help

Specific feedback wanted

  • To store this preference for each login, I propose to add a new property to the login class, called disableAutofill. This change will need to be made to jslib and Server repos. I expect this will need to be made to all permutations of that class, e.g. api, data, domain, request and response classes. Anything I’m missing here?

  • I don’t think we need to display this option in the other clients, because they don’t have autofill functionality and it just wouldn’t make sense in that context. By default, I think they will ignore this new feature because they won’t know to parse and/or display the new property. Does anyone see any issues here?

  • Is there a risk that users see the “do not auto-fill on page load” tickbox and assume that auto-fill is therefore enabled by default for all items? (Rather than first having to enable it globally, and then disable it on a per-item basis.) If so, is there any UX improvement that could help with this?

Timeline to completion (estimate):

ETA: Q4/2020

@tgreer @kspearrin

2 Likes

Not really, that should be pretty simple, just ensure any model binders and update routines for those request/response classes persist that through accordingly (client and/or server-side), including on any other clients which override the views/markup. (don’t forget the models in Mobile)

I would think if I’m adding an item in the desktop app, or my mobile device, I may want to save it with predefined behavior regarding auto-fill in the browser extension; also consistency warrants having all properties for each cipher/item rendered/editable in each client. I would have to leave that up to Kyle ultimately. Also, as an Org admin creating credentials in the web vault, for instance, I may want to pre-configure this setting as well before sharing it to a collection, etc. This would impact all clients, including Mobile.

Yes, assumptions are pretty nasty things, lol, however I think clever labeling may be in order to help resolve this, say something like a checkbox labeled, “Do not auto-fill on page load (when applicable)”, etc. (I’m not an English major, but hopefully that makes sense)

Thanks for the feedback @cscharf, very useful.

I’ve been thinking about how best to implement this from a UX perspective. I agree that clever labelling could clarify how it works, but I think the real issue is that it doesn’t always make sense to enable the setting globally and then disable it on an individual item level.

For example, what if the user only wants to enable the setting for a few login items? They would have to enable the setting globally, and then manually disable it for every single login in the vault, except for the few logins that they do want to auto-fill. This could be a common situation if a user has multiple logins for each site, and only wants 1 login to auto-fill on page load. The logins to auto-fill on page load would be in the minority, which means a lot of time ticking “do not auto-fill on page load” for all other logins.

Rather than a boolean value for each login, how about a drop-down entitled “Auto-fill on page load” with the following options:

  • Use global setting (default option)
  • Always
  • Never

This way, users could use the global setting, or override it on a per-login basis depending on what makes sense for them.

Yes, I think you’re right - those are good use cases and it’s preferable to have consistency across clients.

1 Like

That seems like a much better experience indeed, great thought. With that, having the label simply be Auto-fill on page load (when enabled) should solidify any last confusion since the setting itself would always be visible, including clients that know nothing of auto-fill behavior itself.

This is coming along well, but I am having some difficulty testing in Safari. I can’t find any up-to-date instructions on how to load and debug an unpacked extension - all seem to require that you use Xcode 12 with Safari’s native API, which Bitwarden doesn’t use (afaik). Can you please point me to some instructions for how to do this?

So testing/debugging in Safari can be… uh… “fun” :grin:

Basically you do need:

  • Xcode (latest) installed
  • An Apple Developer account, a free one should do
  • To open the project, src/safari/desktop.xcodeproj, in Xcode (this is a dummy project for side-loading the extension when debugging/developing)
  • To create a developer provisioning profile for self-signing

Then, to debug, you’ll also want (because of conflicts, etc.) to reset/flush your extension reference paths:

  • Open Safari, Go to Preferences -> Extensions, and disable/remove Bitwarden
  • Quit or Force-Quit Safari
  • Uninstall Bitwarden Desktop
  • Open Safari again, Go to Preferences -> Extensions and close (no other action necessary)
  • Quit or Force-Quit Safari
  • You need the page, style and image assets (e.g. the browser extension itself) as well to debug, to do this you’ll need to:
    • Run npm run build in order to get the build output
    • Copy the full contents from build/ (except build/popup/index.html) to src/safari/safari/app (.gitignore already excludes these from source control except src/safari/safari/app/popup/index.html)
    • You’ll need to do this every time you make an update to the browser extension code

When launching the debugger in Xcode it will ask you which process to run/attach to, just select Safari and you should be good to go if all goes well; then go to Preferences -> Extensions in Safari (at least the first time you run) and enable the extension; sometimes Xcode + Safari will automatically add it and enable it for you, but then you can run it and debug it directly in Xcode, set breakpoints in the swift code, etc.

also see: https://developer.apple.com/documentation/safariservices/safari_app_extensions/building_a_safari_app_extension

1 Like