Sorry for the delay… I needed to find some free VPN which can me allow me to use IP address to access auth.max.com and also I believe we are living in different time zones. I am from Europe.
Again, unfortunately I was not able to fill the fields.
Thanks for testing that. I assume that the https://www.royalcaribbean.com/account/signin site also doesn’t auto-fill for you, then. Thus, it is likely that your feature flag did get switched to V1, but that your problem is of a completely different nature.
I forget if you tried this already, but what happens if you disable all of your other browser extensions? For example, you can enable the BItwarden extension to run in Incognito/Private mode, but none of the other extensions.
Now I have tried the link you suggest https://www.royalcaribbean.com/account/signin with or without enabled/disabled all other addons and it’s not filling but it didn’t even displayed that error message.
It’s the same on private mode as well. 
And just to ensure there is no miscommunication: In Private mode, are all of your browser extensions disabled (except for Bitwarden)?
Yes… all other addons (except Bitwarden) on Private mode were disabled.
Thanks for confirming.
Unfortunately, this is starting to reach the end of my troubleshooting abilities. If you haven’t already reached out to Bitwarden’s tech support, you should do so.
Good luck!
Max only available in USA!
@Steve1961 Is there some problem you are experiencing with Bitwarden that you are seeking assistance with?
Hello again,
The issue has returned as same as previously. It stopped filling fields even with several changes on Firefox, with or without other addons and private mode as well… also tried to sync the vault but doesn’t helped that either… 
Sites affected so far:
@skywalker Which version of the extension are you on?
Ensure that you’ve updated the extension to the latest version, v2023.12.0, and autofill should function as normal again. I’ve tested both of the listed websites, and they work as expected on the latest extension release.
@cagonzalez Sorry for not pointing that out. Version 2023.10.2
Aha! So looks like Autofill V2 is enabled again?
Any idea why autofilling still doesn’t work (even with custom fields) on login forms for the ING bank? They use a Shadow DOM, so I had hoped Autofill V2 would be able to handle these sites:
https://areariservata.ing.it/login/?nwp=1
Yes, the updated implementation is enabled.
As for the existing issues, we’ll dig into these examples. Thank you for providing them.
We are aware of another defect with the caching implementation we have in place as described here - Bitwardin 2023.12.0 Auto-Fill not working correctly · Issue #7202 · bitwarden/clients · GitHub
Details for that issue and its resolution can be found at that link.
I saw in the linked GitHub issue that autofill now doesn’t fill invisible elements, which is a great security improvement (even though it is having some side-effects in the current implementation)! Was this just implemented in 2023.12.0?
I have been interested in this issue (vulnerabilities associated with invisible form fields) for some time, and wrote a comment back in March that summarizes my thoughts on the matter — including several proposed strategies for mitigating the risks. If you have the time to read the comment linked below, I would really appreciate it:
As you work to resolve the caching issues in Issue #7202, I would just like to offer my opinion that I hope you will not deal with these difficulties by disabling or watering down the new functionality for preventing autofilling of nonvisible elements. I think it should be in principle be possible to update your cache when a user requests autofilling (via keyboard shortcut, right-click context menu, etc.), and I think it would be perfectly reasonable for autofill on page load to not work on such sites (i.e., I really hope that you don’t water down the new feature just to accommodate those users who have enabled autofill on page load).
I’m unsure of when this was addressed, but when we started work on refactoring the autofill content script, the default behavior was to validate visibility for an element and not fill it if it was not visible. To verify this, we originally checked to see if the element was present in the viewport, if it was hidden using CSS, or if another element was overlaying the field. If any of those checks failed, we would determine the field was not visible and would not fill it.
That carried over into the v2 script, and was working effectively during the “shadow-drop” of the implementation back in October.
The performance improvements we’ve implemented have introduced a number of edge case concerns that we’ve been ironing out for a couple of months now. Regardless, we’re not planning on removing any functionality in order to accommodate these improvements. That includes avoiding filling hidden/non-visible fields.
I dug into these a bit…
For the first link, the site has a number field and a date field that its requesting for user login. We do not fill those fields at all at the moment, so not a lot can be done for these without us revisiting whether we should accommodate some kind of method for filling these field types.
The second two can be filled, however, you’ll need to add a custom field with the name attribute of the input field (which in this case is login). I’m not sure why we don’t fill fields that contain the string login in some manner, but I’m checking on that right now to see if we can update our implementation to reference that without having to set up a custom field.
@cagonzalez Thanks for looking into the ING site issues, and for confirming that you are not considering removing the new safeguards for autofilling of invisible fields.
So, among the three suggestions I had made in March in my discussion with @go12, you have implemented the first, which is great. I would be obliged if you could offer your perspective/opinion on the suggestions in the 2nd and 3rd bullet point of that post:
I’ll bring this up with our team designer, but they’re solid points overall.
I’ll hold off on giving a thoughtful perspective for now, if that’s ok. There is a lot of nuance to consider in both proposals, most of those concerns being around how users expect to work with the browser extension in those scenarios. From a technical perspective, both suggestions are feasible, but changing how users interact with established workflows is always tricky.
1 Like
@grb - Thanks for bringing up these points. I’ve always been concerned about hidden fields and thought there was no way to prevent these from being filled in. I’m happy to hear the answer that they don’t get filled in. I hope your other two points gets serious consideration in getting implemented.
@cagonzalez - Thanks again for taking the time to fix my issue with form filling and present these excellent points from grb to the developers. I rely very heavily on form filling and I’m extremely grateful that time and effort has been put in to improve the experience.
1 Like
Updated to v2023.12.0 and it works. Thanks! 
Although I use the Opera browser, a similar situation happened to me. I can’t fill in the information in the contest form on 2 pages. A week ago, I could fill both of them out fine. Now neither can be filled in, or only one (first) field can be filled in on one. I tried v2023.12.0 for Opera. It didn’t work.
website 1: https://predajne.kaufland.sk/akcie-sutaze/adventny-kalendar.html?cid=F5744B02C0303K21000W01000000
website 2: https://adventnykalendar.cewe.sk/