🇩🇪Germany @anacolautti

anacolautti → created an issue.

anacolautti → created an issue.

Thank you very much @idebr. Always happy to learn something new.

I merged and closed this because there was no feedback against it. Thanks @rkoller for the ticket.

I had an issue with the edit forms, sometimes I would get this error too. I know it is not the same issue, but the patch in #46 fixed my issue. Is this going to be added anytime soon? I am on Drupal 10.3. Thanks.

avpaderno → credited anacolautti → .

Hi again.
We use this patch, so I rerolled it to the current 8.x-1.x / 8.x-1.5 version.

Thanks.

anacolautti → created an issue.

Hi! Can you share the Drupal version and theme you're using?
Thank you!

I'm sorry, please explain what you meant by updating the module.
There is no code in the module so far for this feature.

In my opinion this is not an issue related to the module itself (the focus color comes from the browser), allthough I am willing to implement the solution I mentioned earlier (I haven't yet, I was waiting to see if it was useful for other users as well).

Hi Teresa, yes, thank you. I agree with you, a combination of two colors is best.
This change should be done per site though, and not per Drupal module in my opinion.

I think this is not something that should be fixed from this module.

Again, all I can propose, is that we add a setting of some sort to force this for the icon specifically, only if the administrator so decides.

Oh I'm sorry, I thought the commit was enough. I fixed that now. Thanks for letting me know, I need to check the other closed issues now...!

I'm closing this issue because of inactivity. Feel free to reopen it if needed.

I'm closing this issue because of inactivity. Feel free to reopen it if needed.

I'm closing this issue because of inactivity. Feel free to reopen it if needed.

I think this sounds great! However, I have been unable to find any documentation to assist me in implementing this. Does anyone have an example, perhaps from another core or contributed module, or any documentation links that could help guide me?

Thank you!

Thanks everyone!

Since this was an arbitrary value to begin with, and this issue was opened almost two months ago and no other user complained about it, I think it should not bother anyone that we update it to match these requirements.

Merged and mark as fixed!

anacolautti → made their first commit to this issue’s fork.

Thank you @nilesh.addweb for your help. I added this information on the module's help page and linked to this issue, so that your screenshots are easy to find for other users.
I'm closing this issue as fixed.

Thank you all. I merged your changes, from the MR and the patch, and fixed a few dangling spaces and missing new lines.

This is on dev already.

Hi again, thank you for your input here.

I created a branch to start these fixes.

• Remove "Please" word from the form (2 found)
• Change form labels
• Improve the field descriptions

These are the proposed changes so far:

I'd also update the validation message for the Form id(s) field to be:

The <em>Form id(s)</em> field should contain values separated by commas only. Spaces or new lines are not allowed.

anacolautti → made their first commit to this issue’s fork.

Hi again!
Thank you for your input on this issue. I agree that the low contrast in Safari poses accessibility challenges. However, I believe this may be more of a browser-specific issue, and altering it universally might not be the best approach. Some sites might have their own styles to address this, and we could inadvertently disrupt those.
Instead, I propose offering a “high contrast” setting or a similar feature. This would allow us to enforce focus colors in either light or dark mode within the View Password settings form. We could provide an explanation of its importance, perhaps linking back to this issue, and give site developers the option to enable it deliberately.
What are your thoughts on this approach? Could you assist me in planning this feature?

First of all, thank you for bringing this up, and sorry for the delay in my response.

I think this is a good idea, but I fear the aria-labels might not be adequate if we change this.

Until now, I wrote the aria-labels thinking about the action of the button, which is to either show or hide the password content.
If we change this, the default state of the button would be aria-pressed="false", so the aria label of the button should be something like "password is hidden", and when pressed (aria-pressed="true") it would be something like "password is visible".

Do we agree on this?

Can anyone suggest better texts for these aria labels?

Keep in mind, that updating the aria labels implies updating the translations each site may have done customly and the contrib translations here https://localize.drupal.org/translate/projects/view_password

Hi there, sorry for the delayed response.
I tried reproducing this issue myself in Windows 10 and using Edge 130.0.2849.68, and in Mac using Edge 129.0.2792.79, and in both cases the icon looks fine to me.

I need more information to reproduce this issue.

Thank you for your understanding.

anacolautti → created an issue.

Hi, Sorry for the delayed response.
I"m not familiar with CAS Server. Do you mean this module https://www.drupal.org/project/cas_server → ?
If that's correct, then the form id is cas_server_user_login (check their UserLogin form class at modules/contrib/cas_server/src/Form/UserLogin.php )
I added that form ID to my local form list configuration (separated with commas) and the icon is showing.

I believe this issue is solved, please confirm.

Thanks!

Also, I just noticed when reviewing this other issue 💬 crosseye location Active , that this might be related to the display style of the button. Please check this comment 💬 crosseye location Active to see if this helps us find the issue.

Hi Vako
I enabled the Login popup (2.1.0) on a Drupal 10.3.1 site. Tested the login both with the dev and the 6.0.4 versions, in Edge, Safari, Firefox and Chrome, and I don"t see the issue you're describing.

I noticed though, that the icon could be moved below the input field (like in your screenshot) if the <button class="shpwd">... has a display block instead of inline-block (which should be the default).

This is what I see as styles for the button element:

could you check if yours is also display-inline?

Hi everyone.
First of all, thank you for your interest in this module, and the dedication you spent in creating this issue.
I installed the Bootstrap Barrio → theme, version 5.5.16 on a Drupal 10.3.2 and enabled the View Password module (tried both the dev and the 6.0.4 versions) with the default settings. I don't see the issue you're describing. This is what I see:

To investigate further, I need a bit more help from you, because, I cant fix something that I don't see broken myself.

Could you check which styles are being applied to the Icon and its containers, both with and without extra classes?

This patch worked for me on D10.3.1 and PHP 8.3.10.

greggles → credited anacolautti → .

I tested this issue again in a Drupal 10.1.7, and could not reproduce it anymore.

This is a screenshot of the database in each of the steps mentioned in the ticket:

Could it be, that this got fixed after fixing one of the related tickets?

Thank you very much @sumit-k. This will be in the next release, a week from now (1st April).

I added 2 fields in the settings form, allowing users to enter (version controlled) paths to images.
This overrides the CSS background-image style attribute.

I made some other changes:
- at the JS I changed some selectors. I realized I was using them wrong.
- at the original CSS I changed the background-size attribute of the icons, and set it to "contain". This works better with different icons.

I know this is a minor feature, but I believe this would provide users more flexibility.
I'm thinking of allowing file uploads as well in the next iteration, like I said in the ticket description a while ago.

I'd appreciate if someone could test this.

I know I'm skipping steps here, but I believe this issue is fixed with this change. I'll go ahead and close this. Please feel free to reopen if I'm mistaken.

On the merge request is an attempted fix. I tested this on fresh D9 and D10 installs.
Please take a look.

I missed the fact that you had already proposed a MR (because the status was "new" and I was on automatic...). Although I was not able to reproduce the issue, I came to the same resolution as you from looking at other similar issues. I tested your fix in both Drupal 9 and 10. Thank you for your work, I merged your commit and I'm closing this issue.

Thank you for reporting this. I'm on it.

Hi, Thank you Janner for reporting this. I'm not sure I understand, when you say "status of the button", do you mean the aria-label? I see it's being affected. Look at this video: https://nimb.ws/csVh64

I'll attempt a fix.

Marking this as won't fix. This is not a module issue. In recent updates, Last Pass fixed their behavior. See screnshot, on a fresh Drupal install.

Thank you for your work! This patch has been commited to the 6.0.x dev version.

Sorry, I've been a bit busy lately and it took a while.
Thank you for your contribution to this module. Your patch is now in the 6.0.x dev version.

anacolautti → made their first commit to this issue’s fork.

Hi @wim-leers. Sure, I hope this helps!

I believe this structure change

d9 settings:

settings
  toolbar
    rows 

to

d10 settings:

settings
  toolbar
    items 

is what broke my site. The error line was this one:

web/core/modules/ckeditor5/src/Plugin/CKEditor5PluginManager.php

if (empty(array_intersect($editor->getSettings()['toolbar']['items'], array_keys($definition->getToolbarItems())))) {
  unset($definitions[$plugin_id]);
}

and the error, that the first argument of array_intersect could not be null

In case this helps anyone, we were having a similar error:

TypeError: array_intersect(): Argument #1 ($array) must be of type array, null given in array_intersect() (line 203 of        
                                           web/core/modules/ckeditor5/src/Plugin/CKEditor5PluginManager.php

In our case, it happened because we updated our site to Drupal 10 but the configuration remained unchanged from our Drupal 9 previous version of the site. Then, the config element of the editor had a different structure that the CKEditor5PluginManager could not iterate.

We solved it by either editing and saving the text format again at /admin/config/content/formats, or deleting the faulty text format and creating it again (where the previous solution was not possible).

Thank you Vishakraman! looking forward to see this.
Let me know if you need any help

Thank you all very much for these fixes. Merged from gitlab and and closed!

Thank you very much @urvashi_vora, I really had very little time these past days to close this issue. I just merged the MR.
I'll create a release with this issue fix before the end of next week.

Thank you all!

Hi again!
I was able to reproduce this in D9.5.3. I was not able to reproduce in D10 since the module in use is not yet D10 ready.

Thank you @pmichelazzo for your code. I ended up using the once() function, based on the last fix on the related issue above (Multiple eye icon...). Adding the patch to this comment.

Please someone test this so that I can merge to the development branch and include in the next release.

This is probably related to Multiple eye icon 🐛 Multiple eye icon Fixed .
What browser are you using? and Drupal version? Let me know so I can try to reproduce it.
Thanks!

This release is now published. Thank you all.

Thank you everyone that helped fix this.

Thank you PhilY. I'll merge this and deploy today.

yay!

Ok, this is great, thank you all.
I reviewed the patch and had to do some modifications to be able to keep the functionality in these other issues that we also merged to dev:

- Issue #3228830 → by thalles: Selector previous input password error
- Issue #3324373 → by kkalashnikov, dineshkumarbollu, rishu_kumar, _pratik_: Drupal 10 compatibility

I tested this successfully in drupal/core:9.5.1 and drupal/core:10.0.x-dev.

I cannot reproduce the original bug, so if anyone else can confirm that this patch does the trick, let me know.
I can still add this patch to the dev branch, and merge it into the release 6.0.1 on Jan 30th 🌱 Road to release 6.0.2 Fixed .