Using Never URI for Autofill

But surely not never ever, right? :slight_smile: It should be never for that particular URI.

Just to be clear, I have the specific URL configured with Never and then the entire entry set to autofill on page load (my default in Options is autofill enabled).

Auto-fill on page load is currently experimental (WIP). When disabled, and you cycle through logins using the keyboard shortcuts, does it avoid the one set to ‘never’?

Ctrl/CMD + Shift + L Auto-fill, press again to cycle through matching logins

If so, I can follow up with the team on auto-fill on page load when set to ‘never’.

In this context, does “item” refer to the Login item, or to the specified URI? For example, if I configure two different URIs for a Login item, with the first URI’s matching option set to Base domain and the second URI’s matching option set to Never, are you saying that the second item will override the first, preventing any URI from ever matching, as long as a single URI has been set to “Never”?

I disabled autofill for this entry and confirmed it is disabled for the other three, as well. I loaded the page in question and my credentials were not autofilled. So far, so good.

When I cycle through the logins using Ctrl/CMD + Shift + L, all four logins get filled in turn. So it does seem something is broken with the URI set to Never.

I will say that I think this was working correctly for some time and that the issue appeared within the last couple of weeks - though I’m not certain.

Can this be a solution/work-around for you? When you need to log in as admin, you can use the keyboard shortcut, and you presumably would not apply the autofill keyboard shortcut while on on other users’ profile configuration screens.

Can you check to see if you see the same behavior with a different browser and fresh extension install?

Fresh extension install in Firefox 104:
With the same settings (autofill enabled in Options, preferred login set to autofill, other three logins set to not autofill, and URI on preferred login for the user admin page set to Never), I have the same experience as in Chrome: my preferred login autofills on the user admin page.

Yes, I’ll use this workaround in the meantime. :+1:

@bw-admin I think the documentation is wrong or misleading, as the word “item” evidently refers to the URI itself, not to the Login item within which the URI has been saved. Which brings me back to my original question: in order to determine whether a URI that has been set to “Never” match should be excluded from autofill, does the app require the URI to match exactly, or only to the base domain, to the host, or to the start of the URI for the current page in the browser?

1 Like

In the screenshot, the URL is for the host, but in your original post, you said the problem occured at Which of these two URLs actually shows in the address bar when you are on a user profile configuration screen?

None of those. Never just means ignore the entered URI and don’t try to match it. And it doesn’t affect any other URIs in the item.

My OP was just generalizing. The actual URL matches the screenshot.

@WildWanderer - Your screenshot shows that you have multiple URIs entered in the login item that is autofilling. To troubleshoot which one is causing the autofill, set the match option for ALL of them to Never, and then it should no longer autofill. One by one, set each URI back to the original matching rule to figure out which URI is causing the match and autofill.

What is the point of Never for the URI then? Just to store a URL that will never be used in any fashion except manually referencing/storing it?

Yes, exactly. For example, maybe you just wanted to archive and item and never have it match and autofill. Never is essentially a way to exclude a URI from the matching process without having to delete the URI entirely. But if you ever needed it, you could still search for it manually and view it.

Good idea. The one causing the interference is Starts with -

Evidently, both the admin login screen and the user profile configuration screen have the same host ( If you go to the two pages, can you see any clear differences in the page URLs, following the host name? If so, you can make the stored URL more specific, to avoid false positive hits when on the user profile page.

This resolved the issue! Since I like having access to my default login while on the site, I added some other Starts with URIs for some of the common pages I visit. Then, I have the Never URI for the user admin page and Starts with for the sign-in pages. I also had to add a custom field for the username on the initial login page since it wasn’t picking that up and kept asking if I wanted to save a new login.

I’ll have to file a feature request for a change to the URI config. What I’d like to see is a NOT operator so I can configure something like this:

*URI 1: Starts with
*NOT URI 2: Exactly

So that would have my login available everywhere on the site except the user admin page.

I would also then say to get rid of the Never option and if you want to store a URI that you never do anything with, add it in Notes or as a custom field.


Btw, I didn’t expect to get so much help so quickly. Thank you all for your time! Rockstars.


Glad we were able to guide you to a solution.

I was thinking along the same lines, but I’m wondering if equivalent funcitonality can be achieved using a regex match?

I have another use case for the Never option.
I have several email accounts that are hosted by tenants of Office365.
Therefore, for these login items, I have set the first URI to, with matching set to Never. This lets me use the “Launch” function to go to the main login page for Outlook webmail, without autofilling anything. I then have other URIs that can autofill the password page, which is specific to each host.