2016-08-22 07:03:51 +08:00
|
|
|
{{!
|
|
|
|
This file is part of Moodle - http://moodle.org/
|
|
|
|
|
|
|
|
Moodle is free software: you can redistribute it and/or modify
|
|
|
|
it under the terms of the GNU General Public License as published by
|
|
|
|
the Free Software Foundation, either version 3 of the License, or
|
|
|
|
(at your option) any later version.
|
|
|
|
|
|
|
|
Moodle is distributed in the hope that it will be useful,
|
|
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
GNU General Public License for more details.
|
|
|
|
|
|
|
|
You should have received a copy of the GNU General Public License
|
|
|
|
along with Moodle. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
}}
|
|
|
|
{{!
|
|
|
|
@template core_form/element-passwordunmask
|
|
|
|
|
|
|
|
Moodle passwordunmask form element template.
|
|
|
|
|
|
|
|
The purpose of this template is to render a passwordunmask form element.
|
|
|
|
|
|
|
|
Classes required for JS:
|
|
|
|
* none
|
|
|
|
|
|
|
|
Data attributes required for JS:
|
|
|
|
* none
|
|
|
|
|
|
|
|
Context variables required for this template:
|
|
|
|
* element
|
|
|
|
* id
|
|
|
|
* name
|
|
|
|
* value
|
|
|
|
* size
|
|
|
|
|
|
|
|
Example context (json):
|
|
|
|
{
|
|
|
|
"element": {
|
|
|
|
"id": "example_password_unmask",
|
|
|
|
"name": "example",
|
|
|
|
"value": "Password1!",
|
|
|
|
"size": 40
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
}}
|
|
|
|
{{< core_form/element-template }}
|
|
|
|
{{$ element }}
|
|
|
|
<span data-passwordunmask="wrapper" data-passwordunmaskid="{{ element.id }}">
|
2016-11-23 15:02:33 +08:00
|
|
|
<span data-passwordunmask="editor">
|
2022-09-06 10:45:47 +07:00
|
|
|
<input type="password"
|
MDL-53048 core_form: passwordunmask must exist on page for validation
The initial approach I took was to provide a noscript area containing the
standard input element, and to move it to a hidden input element as part of
the passwordunmask setup.
This allowed behat tests to pass both with and without JS enabled (i.e.
with Goutte and real browsers), and also ensured that the real input did
not appear on screen.
However, the standard formslib validation occurs before other page JS is
run and hooks into the elements on page during its setup.
Since noscript elements are not accessible to scripts as standard elements,
the form validation would fail for _client_ side validation and work for
server-side validation.
This change creates creates the hidden input element in the template
instead, as well as the password element in the noscript tag.
Doing this means that when JS is disabled, the form has two elements of the
same name - one hidden, and the second a visible password field.
Since the latter element will always override the former one on form
submission, and the noscript variant is last, the noscript variant wins
when JS is disabled and tests continue to pass.
When JS is enabled, the noscript variant is not a valid part of the DOM
(the browser sees it as a hidden text field essentially). The password is
not automatically entered into the hidden field, so the autocomplete
prevention continues to work as expected.
2016-10-26 13:33:08 +08:00
|
|
|
{{# element.frozen }}readonly{{/ element.frozen }}
|
|
|
|
{{^ element.hardfrozen}} name="{{ element.name }}"{{/ element.hardfrozen }}
|
|
|
|
id="{{ element.id }}"
|
|
|
|
value="{{ element.value }}"
|
2022-09-06 10:45:47 +07:00
|
|
|
class="form-control d-none {{# error }}is-invalid{{/ error }}"
|
2016-11-23 15:02:33 +08:00
|
|
|
data-size="{{ element.size }}"
|
MDL-53048 core_form: passwordunmask must exist on page for validation
The initial approach I took was to provide a noscript area containing the
standard input element, and to move it to a hidden input element as part of
the passwordunmask setup.
This allowed behat tests to pass both with and without JS enabled (i.e.
with Goutte and real browsers), and also ensured that the real input did
not appear on screen.
However, the standard formslib validation occurs before other page JS is
run and hooks into the elements on page during its setup.
Since noscript elements are not accessible to scripts as standard elements,
the form validation would fail for _client_ side validation and work for
server-side validation.
This change creates creates the hidden input element in the template
instead, as well as the password element in the noscript tag.
Doing this means that when JS is disabled, the form has two elements of the
same name - one hidden, and the second a visible password field.
Since the latter element will always override the former one on form
submission, and the noscript variant is last, the noscript variant wins
when JS is disabled and tests continue to pass.
When JS is enabled, the noscript variant is not a valid part of the DOM
(the browser sees it as a hidden text field essentially). The password is
not automatically entered into the hidden field, so the autocomplete
prevention continues to work as expected.
2016-10-26 13:33:08 +08:00
|
|
|
{{# error }}
|
2019-04-09 14:00:14 +02:00
|
|
|
autofocus aria-describedby="{{ element.iderror }}"
|
MDL-53048 core_form: passwordunmask must exist on page for validation
The initial approach I took was to provide a noscript area containing the
standard input element, and to move it to a hidden input element as part of
the passwordunmask setup.
This allowed behat tests to pass both with and without JS enabled (i.e.
with Goutte and real browsers), and also ensured that the real input did
not appear on screen.
However, the standard formslib validation occurs before other page JS is
run and hooks into the elements on page during its setup.
Since noscript elements are not accessible to scripts as standard elements,
the form validation would fail for _client_ side validation and work for
server-side validation.
This change creates creates the hidden input element in the template
instead, as well as the password element in the noscript tag.
Doing this means that when JS is disabled, the form has two elements of the
same name - one hidden, and the second a visible password field.
Since the latter element will always override the former one on form
submission, and the noscript variant is last, the noscript variant wins
when JS is disabled and tests continue to pass.
When JS is enabled, the noscript variant is not a valid part of the DOM
(the browser sees it as a hidden text field essentially). The password is
not automatically entered into the hidden field, so the autocomplete
prevention continues to work as expected.
2016-10-26 13:33:08 +08:00
|
|
|
{{/ error }}
|
2024-02-01 15:49:28 +00:00
|
|
|
{{#required}}
|
|
|
|
aria-required="true"
|
|
|
|
{{/required}}
|
2022-12-06 12:28:27 +11:00
|
|
|
{{{ element.attributes }}}
|
MDL-53048 core_form: passwordunmask must exist on page for validation
The initial approach I took was to provide a noscript area containing the
standard input element, and to move it to a hidden input element as part of
the passwordunmask setup.
This allowed behat tests to pass both with and without JS enabled (i.e.
with Goutte and real browsers), and also ensured that the real input did
not appear on screen.
However, the standard formslib validation occurs before other page JS is
run and hooks into the elements on page during its setup.
Since noscript elements are not accessible to scripts as standard elements,
the form validation would fail for _client_ side validation and work for
server-side validation.
This change creates creates the hidden input element in the template
instead, as well as the password element in the noscript tag.
Doing this means that when JS is disabled, the form has two elements of the
same name - one hidden, and the second a visible password field.
Since the latter element will always override the former one on form
submission, and the noscript variant is last, the noscript variant wins
when JS is disabled and tests continue to pass.
When JS is enabled, the noscript variant is not a valid part of the DOM
(the browser sees it as a hidden text field essentially). The password is
not automatically entered into the hidden field, so the autocomplete
prevention continues to work as expected.
2016-10-26 13:33:08 +08:00
|
|
|
>
|
2016-11-23 15:02:33 +08:00
|
|
|
</span>
|
|
|
|
{{^ element.frozen }}
|
2020-10-27 13:44:02 +01:00
|
|
|
<a href="#" class="form-control" data-passwordunmask="edit" title="{{ edithint }}">
|
2016-11-23 15:02:33 +08:00
|
|
|
{{/ element.frozen }}
|
|
|
|
<span data-passwordunmask="displayvalue">{{> core_form/element-passwordunmask-fill }}</span>
|
|
|
|
{{^ element.frozen }}
|
|
|
|
{{# pix }} t/passwordunmask-edit, core, {{# str }} passwordunmaskedithint, form {{/ str }}{{/ pix }}
|
|
|
|
</a>
|
|
|
|
{{/ element.frozen }}
|
|
|
|
<a href="#" data-passwordunmask="unmask" title="{{ unmaskhint }}">
|
|
|
|
{{# pix }} t/passwordunmask-reveal, core, {{# str }} passwordunmaskrevealhint, form {{/ str }}{{/ pix }}
|
|
|
|
</a>
|
|
|
|
<span data-passwordunmask="instructions" class="form-text text-muted" style="display: none;">
|
|
|
|
{{^ element.frozen }}
|
|
|
|
{{# str }} passwordunmaskinstructions, form {{/ str }}
|
|
|
|
{{/ element.frozen }}
|
|
|
|
</span>
|
2016-08-22 07:03:51 +08:00
|
|
|
</span>
|
|
|
|
{{/ element }}
|
|
|
|
{{/ core_form/element-template }}
|
2016-08-26 08:29:43 +08:00
|
|
|
{{#js}}
|
2016-08-22 07:03:51 +08:00
|
|
|
require(['core_form/passwordunmask'], function(PasswordUnmask) {
|
|
|
|
new PasswordUnmask("{{ element.id }}");
|
2016-08-26 08:29:43 +08:00
|
|
|
});
|
2016-08-22 07:03:51 +08:00
|
|
|
{{/ js }}
|