Misinterpretation of Certain Names as Reserved Words

[davenull311]

Summary: Users with reserved words as/in their names — such as mine, "Null" — frequently encounter issues with form validation, such as mine being misinterpreted by JavaScript as the primitive value null, for example. This leads to forms being rejected, causing user frustration and hindering accessibility.

Impact: This issue particularly affects systems where JavaScript is used for client-side validation. While rare, this edge case can lead to applications wrongly treating valid string inputs like "Null" as an absence of value. When forms include legally binding information, such as KYC/tax reporting systems, the impact can include delays and/or legal consequences.

Proposed Solution: This is admittedly a complex issue. Trying to differentiate between valid text and reserved words using case sensitivity is unlikely to be accurate or effective. Allowing strong typing of fields within JavaScript is also not ideal given the dynamic nature of the language, web interactivity, backward compatibility, etc.

My idea is to assign an assumed 'string' type for alphabetic-only fields captured within either a "submit" or "onsubmit" Event. Validations could then be performed on that string and handled as desired.

Thanks for any conversation and consideration to this admittedly rare edge case! Dave Null

[ljharb]

Events, and forms, are the purview of the web (and the HTML spec), not the JS language spec.

[bakkot]

First let me express my utmost sympathy for the problems that programmers cause for you and others by being careless and building in bad assumptions about names and other ways that people vary.

Unfortunately, this specific problem is not actually one caused by JavaScript or other parts of the web platform: text-based form inputs are already strings, and there is no relationship between string data and reserved words in JS (unless using eval, which is widely discouraged and in any case would not cause this kind of problem). Rather, the problem lies in other systems, including the websites themselves, building in assumptions about certain strings having special meaning. And while we can do our best to discourage that tendency - for example, we've started discouraging new built-in APIs from coercing between different types of value, such as coercing the actual null value to the string "null" - it is not a problem we can actually solve at the level of the language.

[davenull311]

@bakkot , thank you for your detailed explanation. After @ljharb 's comment I recreated the issue with the DevTools open to see if I could narrow in on the issue. The only clue to what happened was in the element itself:

<div name="LastName" ng-show="FormViewContact.LastName.$error.server" ng-bind="errors.LastName" class="ng-binding ng-scope">Last name can't contain "Null". It must be the name of an individual person</div>

My (bad) assumption was that the type was being checked client-side, and since I know that HTML passes all form input as strings, I reasoned that it was the JS throwing this error via something like if (typeof lastName !== null)....

I appreciate your time and explanations! Unfortunately, it looks like I need to get Fiverr to fix their server-side logic. Should be fun!