ID:1766880
 
Resolved
Input controls marked as password-masked were not initialized properly.
BYOND Version:507
Operating System:Windows 7 Home Basic 64-bit
Web Browser:Firefox 35.0
Applies to:Webclient
Status: Resolved (507.1275)

This issue has been resolved.
Descriptive Problem Summary:
When an input control which's is-password parameter is set to true, will not mask incoming input under the Webclient.

Numbered Steps to Reproduce Problem:
1.- Create a blank project with an interface and a single input.
2.- Set input.is-password to true, compile and host it.
3.- Join through Dream Seeker. You will see how it works as expected.
4.- Now join it through the Webclient and notice how the input can be seen. (No masking)

Code Snippet (if applicable) to Reproduce Problem: None, just an interface.

Expected Results:
The inputted text to be masked instantly with asterisks.

Actual Results:
The inputted text is shown and can be seen and read.

Does the problem occur:
Every time? Or how often? Yes.
In other games? Haven't tested, Yes assumed.
In other user accounts? Yes.
On other computers? Couldn't test, but yes assumed.

When does the problem NOT occur? When using Dream Seeker.

Workarounds:
By using a browser control and HTML, though this isn't a workaround.
Fushimi wrote:
- Input controls does not support the is-password parameter anymore. (In dream seeker it masks the input, whereas in the Webclient doesn't.)

I'm not sure of the relevance or the importance, but using input() as password doesn't mask the input either.
That's exactly what I wrote.

An input control with 'is-password=true' will mask any text entered with asterisks, whereas with it set to false it doesn't.

However, the web client simply ignores the value of 'is-password' and no masking is done.
In response to Fushimi
I disagree. You're referring to the input control. I'm referring to the input() proc. I specified that I'm not sure of the relevance because I don't know how much is shared between these in the client itself.
You are right, didn't notice.
I should read twice for the next time. =)

EDIT: Didn't know that input() as password didn't mask it either, another one to the list then.
Labels' background images should be visible. I've tested them myself. However it is very important to report each bug separately.
What about both inputs' issues?

Should I do another report for them?
Yes, separate reports for each issue--even if it's for the same control (although that doesn't appear to be the case). If they're different issues they need different reports, so I can deal with them separately.

[edit]
This thread can be kept for one of those issues, so it's just a matter of deciding which one to keep here and which ones get new posts.
Edited, will be posting the rest of issues on separate posts.
Since you said label's background works properly I will avoid it until I deeply test it.
Lummox JR resolved issue with message:
Input controls marked as password-masked were not initialized properly.