Text in electron-port-textbox acts as if 'insert' is on & deleting creates spaces

[karanbirsingh]

Describe the bug

When entering a port in the android textbox, moving the cursor back and typing leads to two oddities:

• typing over an existing character replaces it
• deleting a character via backspace replaces it with a space

To Reproduce Steps to reproduce the behavior:

1. yarn start:electron
2. type in 12345 in the enter-a-port control
3. move cursor between 123 and 45
4. type a number or press backspace

Expected behavior

Backspace should remove the character instead of showing a space. Adding a new character should not replace an existing character (although this may push the limit over 5 - @ferBonnin @cheade what is best?)

running on Windows at this commit point

[msft-github-bot]

This issue has been marked as ready for team triage; we will triage it in our weekly review and update the issue. Thank you for contributing to Accessibility Insights!

[ferBonnin]

Per conversation with Peter his guess is that we are enforcing only 5 numbers, which is expected but may have the side effect of been disconcerting for the user. Recommendation is to review expected behaviour of numeric constrains in electron text boxes (did we enforce it or is it done by the Electron control?) Also, given that the port number is hard-coded, why don't we pre-populate the text box with that number?

[msft-github-bot]

This issue requires additional investigation by the Accessibility Insights team. When the issue is ready to be triaged again, we will update the issue with the investigation result and add "status: ready for triage". Thank you for contributing to Accessibility Insights!

[smoralesd]

We are using Office UI Fabric's MaskedTextField (one of the sub classes of the TextField component). This seems to be the default behavior of this control. You can check this code pen to play with the control. I do notice a little difference between our usage and the examples on Office UI Fabric website: on our case the placeholder values dissapear when the users input the first number, while on Office UI Fabric example, the "mask" stays visible until the user override all the characters. I think this behavior difference comes from a prop we are passing to the control: maskChar=""

[ferBonnin]

Per conversation with Peter and looking at Sebastian comments, this is by design

[msft-github-bot]

This issue has been marked as being beyond the support scope of Accessibility Insights. It will now be closed automatically for house-keeping purposes.