Possible placeholder anomaly with modal pages

I have encountered a possible anomaly in the behavior of placeholder text in modal pages.

I have a login page with a link entitled “forgot password”. This link gives access to other pages allowing the password to be reset. All pages are modal in order to hide all navigation from them.

Clicking on “forgot password” leads to a page that requests the user email. On the page there is a Cancel button that allows the user to return to the login page. The return to the login page is done using the “Navigate back to root” workflow.

Looking back at the login page, I see that the email field displays the email value that I entered in the request page. The curious thing is that the email value does not display as data but as Placeholder text.

Continuing along the reset pages, I have another one that is used to reenter the new password. Clicking on Cancel to return to the login page, I see the password value appearing in the login password field. Worse, THE PASSWORD DISPLAYS AS PLAIN TEXT. The reason is that the password is displaying as Placeholder text.

All variable names have different names. The problem seems to occurs in Input fields with same Label name.

The possibility that, under certain circumstances, a password may accidentally be shown in plain text is really unsettling.

Hi, thanks for reporting! Just to be sure, is the placeholder text where the wrong value is being shown a static text and not bound to any variable? I can imagine this happening if the placeholder text and the input value are somehow bound to the same variable.

Thanks so much for your quick feedback. The placeholder text is bound to a formula that use LOOKUP to display multi-lingual text messages. The fields displaying the problem share the same formula. For example: LOOKUP(app.vars.dictionary.lbEmail, appvars.currentLanguage). When I eliminate the placeholder statements, the problem disappears. Still, the possibility of inadvertently revealing sensitive information through identical placeholder statements is frightening.

Okay, thanks again for sharing the details! It’s definitely a bug, we’ll look into this.