[SOLVED] autofill Opera

Hi,
I have a phenomenon, that my Opera browser makes in some fields an autofill in user edit form and then he cannot save the data anymore. I had added autocomplete="off" in the form and input, but this doesn't help here.
I have no clue what Opera recognize, I have renamed the field name and the label, no result.
I want to be save for my customers, who are using Opera with this mad behavior and I am wondering, how I can prevent such things generally in CB fields for any browsers.
Do you have an idea?
Thanks, best regards

I found a solution, has something to do with my special solution to separate password etc. and further profile data with display: none. Saving-Button checks some fields and if I only have email field hided, but it is shown in code, then it works.

So my wish for an official possibility to have 2 areas, one area for account data and the second for further profile data, as I see it in most websites, remains.

all ok so far, not needed post anymore

We already set autocomplete="off" on the entire profile edit form and for password fields. We'll be adding some additional autocomplete usages as there's some newer ones, but in the end it's entirely up to the browser if they want to respect that attribute. The same applies to password managers ignoring it. The profile edit password field and login password field even have different input names to try and avoid this, but that often doesn't work either since autofill just blank fills all password inputs on the page a lot of the time.

We are not going to split up profile edit to multiple page loads, sorry. That's going backwards as far as UX is concerned. Profile data should be in a centralized place allowing users to review and modify their data in a singular location. Putting there data across multiple pages is bad UX. One of the better UX options is to just use CB Core Fields Ajax and allow your users to inline edit their fields so they can edit what they feel like editing directly on their profile. Ideally once CB Core Fields Ajax can support editing an entire tab at once it'll be the best option since it allows by-section editing.

Really a pity. In my view two seperate areas are user friendly. One for the account data and one for the profile data fields, which shall be shown to the public or users. If the user want to change his password or want to export his data, he shall not see all his data, that is too much. That is in my view a better UI. And this would be the beginning of development to a application component rather then "only" a community component. CB is so good and fantastic, would be nice if I could make even applications with it (I wish a 1:n data possibility, may be groups with custom fields are the first step to this). So excuse me, that are only my wishes ...

The point of tabs in profile edit is data separation to prevent overwhelming the user with a giant list of fields yet also give them access to all of their data at the same time. Ensure your data is properly separated to multiple tabs for strongest UX in profile edit. Spreading it across multiple page loads is bad UX. Especially when it comes to mobile where backing out and navigating through page after page to change their data is cumbersome. CB isn't only a community component. Profiles can be used for whatever you want. You can also create unlimited component endpoints using CB Auto Actions for all kinds of custom behavior (e.g. Field action as an endpoint for a custom HTML form to update profile data).

With that said there are plans to improve CB Conditional to be able to better handle this usecase to allow URL filtering profile edit more effectively. I don't see this changing in core CB anytime soon, but likely be possible once we've our layouts functionality implemented in a distant CB release.

CB GroupJive will indeed support custom fields in a future release once we decouple fields from profiles making them more of a generic API that we can use anywhere. That should happen in CB 3.0 ideally, but I don't know when that'll be as of yet.