19 ms·

I can't use my number pad for 2FA codes

217 points by edent 3y ago

Sayrus 3y ago
Hijacking back button, shortcuts and key events has to be one of the most annoying thing. This breaks autocomplete/autocorrect, paste and many other use-case like the author encountered. Related to accessibility concerns of numeric and number input, there is a good blog post from UK Gov that was on the front page a (long?) while ago: https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-design-system-team-changed-the-input-type-for-numbers/ https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-des...
- HPsquared 3y ago
  Duckduckgo search bar is infuriating here. I'm always pressing Home/End to edit my query, and those keystrokes don't register.
  - gruez 3y ago
    >I'm always pressing Home/End to edit my query, and those keystrokes don't register. I just checked and it seems like they hijacked it so it navigates the search suggestions instead (ie. pressing "end" goes to the last suggestion)?
    - crtasm 3y ago
      Home/end work normally for me but pressing up/down to scroll the page jumps a different amount because they've hijacked it to switch result. It also means if I've pressed page down, then press down it jumps upwards to the top of the page. Extremely user-hostile choices.
      - eviks 3y ago
        Oh, this one is the worst! Why do they never implement support for simple rebindings when developing such breaking features?
  - gtk40 3y ago
    Ctrl+A and Ctrl+E work as expected on macOS. They must be testing on that OS only.
OJFord 3y ago
And let me paste. Especially if you're going to insist on doing it by SMS (also though please don't) then surely you should know that both Android and iOS make it easy and prominent to copy the code to clipboard...
- trollbridge 3y ago
  One of my favourite features in Brave is “Force Paste”.
  - puttycat 3y ago
    In Firefox AFAIK right-click always opens the menu with a Paste option.
    - echoangle 3y ago
      But that’s the same as pressing the paste shortcut. I guess the force option emulates keypresses or something like that to always allow paste, which the right click option of Firefox doesn’t do.
      - HeatrayEnjoyer 3y ago
        FF has force paste now too
    - kps 3y ago
      Also, in Firefox SHIFT+right-click always opens the menu, even when the site has tried to hijack right-click.
- simonjgreen 3y ago
  I’m a fan of the extension ‘Don’t f** with paste’
  - gruez 3y ago
    I don't often see websites blocking paste on OTP code fields. What I do see often is websites breaking up the OTP field into n separate input fields, and having some code that auto-switches between the input fields as you type them. However, the auto-switching code doesn't handle pastes, so if you try to paste the entire code only the first digit gets entered. ‘Don’t f* with paste’ doesn't help with that.
bradley13 3y ago
Overly controlling code like this also prevents copy/paste. For example, I have had to manually type passwords from my password manager, because a form refused to let me paste from the clipboard.
- pquki4 3y ago
  And too many websites force you to type the 2FA code, like, actually hitting the keys one after another, instead of allowing pasting the code despite the fact that they send the 6 digits to your email.
  - RulerOf 3y ago
    The most annoying form of that was actually featured in the related section of TFA: six individual input boxes.^1 I've seen some of these that magically work with paste, but plenty that don't. [1]: https://shkspr.mobi/blog/2023/10/firefox-might-remember-old-2fa-logins/ https://shkspr.mobi/blog/2023/10/firefox-might-remember-old-...
  - rob74 3y ago
    ...and despite the fact that it's a single use code that expires after a few minutes. I mean, a password in the clipboard could conceivably be a security risk if you leave your computer unlocked, but a 2FA code?
- NovemberWhiskey 3y ago
  Developers who think they're doing the world a security favor by inhibiting paste into password boxes have a special place in hell.
  - rob74 3y ago
    Maybe the developers even know better, but were forced to do it by project managers (or other management)? Because this sounds like just the kind of "security issue" a manager could get hung up on...
xena 3y ago
This is why my keyboard lies and makes the numpad look like the number keys above the keyboard. It just makes things easier in the long run.
- dexterdog 3y ago
  You probably don't want web pages seeing that you use a numpad for typing numbers anyway. It's just another fingerprinting vector.
  - slig 3y ago
    How would the browser even know that, since the keyboard is sending the different codes over the wire.
    - zamadatix 3y ago
      You've pretty much dug out your own answer: The browser exposes both event.key and event.code in the keypress event. If it didn't life would be pretty miserable for interactive content expecting positional things like wasd.
      - slig 3y ago
        The parent of the comment I replied said that their kb lies about the key being pressed, so there's no way for the browser to know and fingerprint the user as the comment I replied implied.
    - creesch 3y ago
      Tell me you haven't read the article without telling me you haven't read the article ;) Not only does your browser know the character code, it knows the key that is pressed. For details I do recommend reading the article itself.
      - slig 3y ago
        I did read the article. The parent of the comment I replied to said that their keyboard lies about the key being pressed.
jwr 3y ago
I wrote a long comment about text-fields being overly aggressive and controlling, but then I clicked and accidentally dragged in my browser's URL text field (this should have selected some of the text!), and the page got reloaded, which deleted my comment. I give up. But I guess at least this proves my point.
- eviks 3y ago
  One slightly inconvenient workaround is using GhostText and then using a proper text editor for long comments - precisely to avoid the eagerly-user-input-destroying web
  - ehecatl42 3y ago
    I am about 24 hours into using ghostText after losing a significant amount of effort to a distracted `C-w`. Browser tab gone; much swearing ensued. I was tempted to start logging my own keystrokes after this… but that's not a good idea. With this extension (+1), I'm happy that `C-w` does as God, readline, and Emacs intended.
    - eviks 3y ago
      Yeah, that's another fundamental fail of the OS - it should allow you to simply register an "OS input editor" that can be used in any text input field so you can use all the features (including recovery) of a dedicated text editing app instead of relying on whatever shoddy substitution some apps have come up with
jchw 3y ago
> Perhaps developers need to test on something other than MacBooks? Another sign that the website you are on was only tested on macOS used to be scrollbars everywhere, since there is no visual difference between overflow: scroll and overflow: hidden. Unfortunately now the default in most places seems to be hidden scrollbars, which is great because if a page or component happens to layout just right, it will simply look like there's no more content and you'll have to rely on the user just knowing they can scroll or you have to add additional cues. If only there was some standard visual cue that could indicate that you can scroll and how far in you currently are! (And of course, the wrong overflow values are still hiding everywhere, so it didn't really fix the problem...)
- nayuki 3y ago
  Scrollbar blindness ( https://news.ycombinator.com/item?id=24293421 https://news.ycombinator.com/item?id=24293421 , https://www.reddit.com/r/programming/comments/ihq8c3/scrollbar_blindness/ https://www.reddit.com/r/programming/comments/ihq8c3/scrollb... ) is infuriating to me as a non-Mac user.
  - aembleton 3y ago
    Seems that the page those discussion are about is unavailable. Fortunately archive.org has got it: https://web.archive.org/web/20210409223357/https://svenkadak.com/blog/scrollbar-blindness https://web.archive.org/web/20210409223357/https://svenkadak...
bastawhiz 3y ago
Maybe this is a hot take, but the `key` API in the dom was a massive mistake. I've been writing JavaScript since the aughts and I've never managed to use it in a way where it didn't feel like a mistake. It's always issues like this, where certain keys don't have the value you expect. Or capitalization becomes an issue. Or modifier keys get in the way. Or god forbid your user has a keyboard with a weird layout or does chording and the API just completely gives up. As ugly as the keyCode/which APIs are, they work. I've never had an issue with them.
- kps 3y ago
  `keyCode` are just raw Windows codes, which are a mess if you ever stray from Windows or US English. `VK_A` does not necessarily correspond to an ‘a’ and does not necessarily correspond to the same position as A on a US keyboard — in general there is nothing you can reliably say about it. `code` is useful for key positions, e.g. for WASD movement in a game. `key` is useful as the interpretation of a key, but primarily for non-text keys, since IMEs and virtual keyboards mean that text does not necessarily correspond directly to keys.
notresidenter 3y ago
I see more and more website use multiple inputs with JavaScript to handle automatically moving from one to the other for OTP codes, including GitHub. It's always buggy because the devs reimplement basic navigation (focus, deletion, arrow keys, etc.) and it turns out that stuff is hard to get right, so they get it wrong. Often, just typing too fast breaks those inputs (<https://github.com/login/device/ https://github.com/login/device/> for example). A simple input is much better, even at the cost of a UI that is slightly more ambigous for the user on desktop (on mobile, there's a bagillion things to make inputting OTP codes easy).
- haolez 3y ago
  Yeah, I think basic input with some magic when using "paste" from different source formats is the way to go.
eviks 3y ago
You could use listening to keys to make input more ergonomic: for example, allowing uio jkl m,. to be used as a keypad so you don't need to move your hand to the actual keypad. Or you can break actual keypads.
- vel0city 3y ago
  I personally never really cared for this setup, as on most keyboards that pattern is staggered and tilted while trying to emulate the straight number pad layout. The straight lines of the number pad are kind of the whole point to me for having a separate number pad area. Meanwhile all the numbers are still there on the regular keyboard just one row higher than you're normally typing. Plus, for a lot of typing a typist is already pressing the symbols on the number row anyways, so it's not like a typist is having to stretch to locations they're not normally pressing anyways. I'm not an accountant or mathematician or whatever so I tend to eschew number pads, so I'm probably a bit biased.
  - eviks 3y ago
    > it's not like a typist is having to stretch to locations they're not normally pressing anyways. But they have to stretch, that's the issue, why do something unergonomic when you can do it better? On phones you have numpad input for the same reason - it's more convenient than the "familiar" horizontal keys > straight lines of the number pad are kind of the whole point to me for having a separate number pad area. But your fingers aren't straight, so that's also suboptimal. On the other hand you don't need to move your hand off home row and can also add more convenient backspace for error correction
    - vel0city 3y ago
      > But they have to stretch People already routinely type at least !, @, and $ often enough and it doesn't seem to be that big of a deal. > On phones you have numpad input for the same reason Yes, a straight grid of numbers for touchscreens not one heavily skewed to the side. Also, the number pad keyboard means larger hitboxes for numbers to type them faster. There's also no real "home row" on a phone keyboard. Look, if it makes you happy, do it. I'm just suggesting that to me its not really that much better than just pressing the keys that are practically always there on any regular keyboard. I'd personally just rather get better at pressing the number row keys instead of ensuring I'm on a keyboard or OS configuration to allow me to have some non-standard numberpad layer on the keyboard.
thesuitonym 3y ago
I really hate how modern developers try to reinvent forms. They always, always get it worse than the basic OS/HTML forms we've had for decades. Those dead stupid, simple forms were highly accessible, very performant, and easy to understand. It seems like forgotten information, but all of these computer interfaces that were invented in the 80s and 90s were built by doctorate level professionals who spent years thinking about these things. Why do all these bozos who took a six month code boot camp (or at best, finished a four year degree with a 2.9 GPA) think the ten minutes they spent thinking about it lead to some brilliant insight?
- cqqxo4zV46cp 3y ago
  I work with a lot of “doctorate-level professionals”. They are as flawed as everyone else. You took “don’t reimplement the browser”, something that is generally incredibly true, and cargo-culted it into placing some old farts on a pedestal just because they were there ‘first’.
  - kunley 3y ago
    That's still an anecdotal evidence (that you in particular find them flawed) against a common sense.
  - thesuitonym 3y ago
    You're right that they're as flawed as anyone else, but the point still stands that they spent years studying these problems. Years that modern developers, especially front end developers just don't have. I'm not saying these ideas shouldn't be revisited, but if you're going to revisit them, do it at an academic institute, where you can spend time figuring out the problems, not at your commercial job where you have to ship next week, no matter how broken it is.
    - Bockit 3y ago
      What’s special about front-end developers here?
dmitrygr 3y ago
We have forgotten that the browser was meant to be the user's agent
gspencley 3y ago
> Perhaps developers need to test on something other than MacBooks? This. So much this. I've gotten down-voted in the past for being really harsh on Macs, this is because I've worked places where the company would only issue MacBooks to its developers, and requests for non-Macs were denied by a blanket policy. So I kind of hold a grudge that's more fairly directed at the companies rather than Apple (but still, Apple's "our way or the highway" approach is antithetical to my way of interacting with computers). These company policies not only affect developer productivity when your engineers have decades of experience training themselves to be productive on their non-Mac system of choice, but it gets so much dumber when your company officially supports non-Mac-using users.
- wodenokoto 3y ago
  Isn’t the reverse just as stupid? Like, my company only dishes out Dells. I’m harsh on dell, but it’s not because of a company supplier contract.
  - OJFord 3y ago
    The non-stupid reverse would be not to deny the requests for non-macs? So you'd have a mix of Dell Inspirons (or whatever) and MacBooks according to what was requested; some Edge users, some Chrome/Firefox but on Windows or Linux users, etc.
  - gspencley 3y ago
    Well, yeah. For the productivity reason it's weird to tell engineers that they must use either a PC or Mac (and forget blanket "PC", if you're most productive on Linux or FreeBSD then ideally engineers can use those). The one rationale that makes sense to me when it comes to restricting choice to a certain degree is the ability for IT to remote-wipe if necessary. How important that is will depend on context. At my current place of work, most company data is accessed through various web applications so if the computer were compromised, there is no sensitive data kept locally that would require wiping. Though I suppose it could be argued that browser caches could be sensitive, and even if you couldn't sign on to those web apps, due to MFA, an attacker could still get information about procedures and tech used that would get them closer. But if they're using JAMF or something they can at least support Windows and Mac. The only other reason that I can think of that a company would have such a policy is economic... but lost productivity and user frustration is a hidden cost, so how real the economic advantages of standardizing are is something I question.
mrozbarry 3y ago
My general philosophy on this is clients will find ways to circumvent literally any special validation you are doing because they are vaguely in charge of their browser. Definitely use html form types, input, and pattern to attempt to ensure the user can't just do something wrong, but the backend needs to be the authority on what is actually valid. I like this unix style "strings as the universal data type" idea - it's not about how it happens, it's about the output. I honestly can't comprehend how something thought it was better to do `const validKeys = [NUMPAD_1, NUMPAD_2, ...];` and not `const validCharacters = '01234567890';`.
8organicbits 3y ago
This sort of complexity is a major reason I've been moving in the direction of dropping Javascript on sites I build. My last web app only used 4 lines of JS for dismissing messages. Django SSR, templates, forms, and plain HTML work in extremely predictable ways. It's much easier to reason about and test plain HTML.
deleted 3y ago
[deleted]
kps 3y ago
Using `code` here is pure ineptitude. It represents the physical position of a key, and is only useful for things like games using WASD movement; the same physical key routinely maps to different inputs under different languages and layouts. And `code` might not be set at all for on-screen (e.g. phone) keyboards. And IMEs don't necessarily send key events at all.
kmfrk 3y ago
A small peeve that frustrates me to no end is when I want to enter some numbers in iOS, and the app gives me a qwerty keyboard interface instead of a numpad. Such a small thing, but it drives me up the wall.
lnxg33k1 3y ago
One great concept I find very useful is just fail, like this thing of not showing letters is just wasted work, it has all the potential to be stressful without adding any value, let the user type whatever they want, if the result match the expected value, go ahead, otherwise retry
moistness 3y ago
This is incredibly hard to figure out. It’s not common sense to never touch the field while the user is interacting with it. - do not prevent default - do not limit my input to the exact number of characters - do not listen to any event other than “blur” unless you’re updating another part of the UI in real time I really wish that browsers gave control back to the users, and I say this as a FE developer.
- ryandrake 3y ago
  > I really wish that browsers gave control back to the users Exactly this. Browsers have stopped doing their job as the "User's Agent" and instead are acting more in the interest of web developers. Consequently, developers now see the browser window as a limitless empty canvas that they can just do whatever they want in, regardless of the user's desires.
cruffle_duffle 3y ago
While we are bitching about crappy inputs on websites, I haven’t seen anybody mention a bug I see on some sites. If you autofill things, the websites validation code doesn’t get triggered and will act like you didn’t enter anything in the fields that got autofilled. It’s like they are explicitly waiting for keystroke events to trigger a “user entered something” and forgot to add an “OR $(shit is in the field)” to their conditional. As a result you have to go back to all the autofilled fields and type something to trigger their validation logic. Annoying….
grishka 3y ago
Another pet peeve of mine is that some websites would intercept Cmd+F to provide their own, usually inferior, version of search, and all browsers being complicit. I wish there was a setting that would prevent websites from overriding browser's own hotkeys.
- account42 3y ago
  More than a setting, maybe it's time we had a separate browser for websites without all these app features.
butz 3y ago
On the bright side, they did not force you to "enter" 2FA code using spinner from "number" input field.
- vel0city 3y ago
  I'm imagining a drop down with all values between 000000 and 999999. And they somehow override the ability to just type into it to jump to the right value, you need to find it. And the list is unordered and randomized every page load.
  - BizarroLand 3y ago
    How about a 6 digit RNG, click to get a number, if it's your number, then you click submit, otherwise re-roll. Of course, your 2FA updates every 30 seconds so hurry.
    - vel0city 3y ago
      Obviously, you'd want to add some anti-spam cooldowns to the number generator as well. To prevent abuse, of course.
deleted 3y ago
[deleted]
mrweasel 3y ago
On a similar note, the Danish government issues ID system doesn't work well with password managers. If the password managers fill in your username, you need to hit space to unlock the sign-in button. The password field, while it does support copy-paste, somehow manages to lock out password managers, so you need to open the password manager, copy your password and then paste (for some reason that field doesn't have the "forget to unlock sign-in" on paste feature.
gloosx 3y ago
Clearly the dev responsible for the input made a mistake, but why does it extrapolate into that javascript hatred? Like, before javascript is was impossible to make a mistake? The whole web was a perfect place without an issue?
- ninkendo 3y ago
  Before JavaScript it was impossible to make this mistake, yes. The web was originally envisioned such that the hypertext described the form elements and the browser was responsible for the UI behavior. JavaScript brought the idea of a Turing complete language you can use to completely define the behavior of your UI, and with that it brought the possibility of an infinite number of mistakes that devs can make. JavaScript violates the rule of least power in this regard: https://en.m.wikipedia.org/wiki/Rule_of_least_power https://en.m.wikipedia.org/wiki/Rule_of_least_power
  - gloosx 3y ago
    > Before JavaScript it was impossible to make this mistake Before JavaScript it was impossible to even implement such functionality on the client side... There was no "number" input before HTML5 spec which came out in 2008, and was adopting for 6 years before finally becoming a recommendation in 2014. You had to let user put any text in the input and do the validation on the backend, which had the same Turing complete language running letting you make any mistakes you want. Rule of least power is just a design principle, and it could not hold as an axiom of good design for the web, because when the least power becomes not enough power, it takes years for the adoption of new powers needed – that's why JavaScript exists in the first place.
letsSpy 3y ago
also, let me paste my email in signup forms and don't ask me for it twice
dramm 3y ago
Thanks. I enjoyed the hour I spent reading about Alphonse Chapanis.
chrismorgan 3y ago
> There are two ways to do this - a right way and a wrong way - using KeyboardEvent. I reject this strongly: they’re both wrong. It’s not reasonable to control this via a KeyboardEvent at all. If you want to do this sort of thing, you should only manipulate in real-time based on the input’s value and selection, triggering on 'input' events when !event.isComposing. Otherwise, you will break things for some users. Also, you should very, very strongly consider not manipulating the field contents, but only validating (and somewhat relaxed masking at that). The web just doesn’t give good, robust primitives for input masking.

217 points by edent 3y ago

Hijacking back button, shortcuts and key events has to be one of the most annoying thing. This breaks autocomplete/autocorrect, paste and many other use-case like the author encountered. Related to accessibility concerns of numeric and number input, there is a good blog post from UK Gov that was on the front page a (long?) while ago: https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-design-system-team-changed-the-input-type-for-numbers/ https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-des...

HPsquared 3y ago
Duckduckgo search bar is infuriating here. I'm always pressing Home/End to edit my query, and those keystrokes don't register.
- gruez 3y ago
  >I'm always pressing Home/End to edit my query, and those keystrokes don't register. I just checked and it seems like they hijacked it so it navigates the search suggestions instead (ie. pressing "end" goes to the last suggestion)?
  - crtasm 3y ago
    Home/end work normally for me but pressing up/down to scroll the page jumps a different amount because they've hijacked it to switch result. It also means if I've pressed page down, then press down it jumps upwards to the top of the page. Extremely user-hostile choices.
    - eviks 3y ago
      Oh, this one is the worst! Why do they never implement support for simple rebindings when developing such breaking features?
- gtk40 3y ago
  Ctrl+A and Ctrl+E work as expected on macOS. They must be testing on that OS only.

OJFord 3y ago

And let me paste. Especially if you're going to insist on doing it by SMS (also though please don't) then surely you should know that both Android and iOS make it easy and prominent to copy the code to clipboard...

trollbridge 3y ago
One of my favourite features in Brave is “Force Paste”.
- puttycat 3y ago
  In Firefox AFAIK right-click always opens the menu with a Paste option.
  - echoangle 3y ago
    But that’s the same as pressing the paste shortcut. I guess the force option emulates keypresses or something like that to always allow paste, which the right click option of Firefox doesn’t do.
    - HeatrayEnjoyer 3y ago
      FF has force paste now too
  - kps 3y ago
    Also, in Firefox SHIFT+right-click always opens the menu, even when the site has tried to hijack right-click.
simonjgreen 3y ago
I’m a fan of the extension ‘Don’t f** with paste’
- gruez 3y ago
  I don't often see websites blocking paste on OTP code fields. What I do see often is websites breaking up the OTP field into n separate input fields, and having some code that auto-switches between the input fields as you type them. However, the auto-switching code doesn't handle pastes, so if you try to paste the entire code only the first digit gets entered. ‘Don’t f* with paste’ doesn't help with that.

bradley13 3y ago

Overly controlling code like this also prevents copy/paste. For example, I have had to manually type passwords from my password manager, because a form refused to let me paste from the clipboard.

pquki4 3y ago
And too many websites force you to type the 2FA code, like, actually hitting the keys one after another, instead of allowing pasting the code despite the fact that they send the 6 digits to your email.
- RulerOf 3y ago
  The most annoying form of that was actually featured in the related section of TFA: six individual input boxes.^1 I've seen some of these that magically work with paste, but plenty that don't. [1]: https://shkspr.mobi/blog/2023/10/firefox-might-remember-old-2fa-logins/ https://shkspr.mobi/blog/2023/10/firefox-might-remember-old-...
- rob74 3y ago
  ...and despite the fact that it's a single use code that expires after a few minutes. I mean, a password in the clipboard could conceivably be a security risk if you leave your computer unlocked, but a 2FA code?
NovemberWhiskey 3y ago
Developers who think they're doing the world a security favor by inhibiting paste into password boxes have a special place in hell.
- rob74 3y ago
  Maybe the developers even know better, but were forced to do it by project managers (or other management)? Because this sounds like just the kind of "security issue" a manager could get hung up on...

xena 3y ago

This is why my keyboard lies and makes the numpad look like the number keys above the keyboard. It just makes things easier in the long run.

dexterdog 3y ago
You probably don't want web pages seeing that you use a numpad for typing numbers anyway. It's just another fingerprinting vector.
- slig 3y ago
  How would the browser even know that, since the keyboard is sending the different codes over the wire.
  - zamadatix 3y ago
    You've pretty much dug out your own answer: The browser exposes both event.key and event.code in the keypress event. If it didn't life would be pretty miserable for interactive content expecting positional things like wasd.
    - slig 3y ago
      The parent of the comment I replied said that their kb lies about the key being pressed, so there's no way for the browser to know and fingerprint the user as the comment I replied implied.
  - creesch 3y ago
    Tell me you haven't read the article without telling me you haven't read the article ;) Not only does your browser know the character code, it knows the key that is pressed. For details I do recommend reading the article itself.
    - slig 3y ago
      I did read the article. The parent of the comment I replied to said that their keyboard lies about the key being pressed.

jwr 3y ago

I wrote a long comment about text-fields being overly aggressive and controlling, but then I clicked and accidentally dragged in my browser's URL text field (this should have selected some of the text!), and the page got reloaded, which deleted my comment. I give up. But I guess at least this proves my point.

eviks 3y ago
One slightly inconvenient workaround is using GhostText and then using a proper text editor for long comments - precisely to avoid the eagerly-user-input-destroying web
- ehecatl42 3y ago
  I am about 24 hours into using ghostText after losing a significant amount of effort to a distracted `C-w`. Browser tab gone; much swearing ensued. I was tempted to start logging my own keystrokes after this… but that's not a good idea. With this extension (+1), I'm happy that `C-w` does as God, readline, and Emacs intended.
  - eviks 3y ago
    Yeah, that's another fundamental fail of the OS - it should allow you to simply register an "OS input editor" that can be used in any text input field so you can use all the features (including recovery) of a dedicated text editing app instead of relying on whatever shoddy substitution some apps have come up with

jchw 3y ago

> Perhaps developers need to test on something other than MacBooks? Another sign that the website you are on was only tested on macOS used to be scrollbars everywhere, since there is no visual difference between overflow: scroll and overflow: hidden. Unfortunately now the default in most places seems to be hidden scrollbars, which is great because if a page or component happens to layout just right, it will simply look like there's no more content and you'll have to rely on the user just knowing they can scroll or you have to add additional cues. If only there was some standard visual cue that could indicate that you can scroll and how far in you currently are! (And of course, the wrong overflow values are still hiding everywhere, so it didn't really fix the problem...)

nayuki 3y ago
Scrollbar blindness ( https://news.ycombinator.com/item?id=24293421 https://news.ycombinator.com/item?id=24293421 , https://www.reddit.com/r/programming/comments/ihq8c3/scrollbar_blindness/ https://www.reddit.com/r/programming/comments/ihq8c3/scrollb... ) is infuriating to me as a non-Mac user.
- aembleton 3y ago
  Seems that the page those discussion are about is unavailable. Fortunately archive.org has got it: https://web.archive.org/web/20210409223357/https://svenkadak.com/blog/scrollbar-blindness https://web.archive.org/web/20210409223357/https://svenkadak...

bastawhiz 3y ago

Maybe this is a hot take, but the `key` API in the dom was a massive mistake. I've been writing JavaScript since the aughts and I've never managed to use it in a way where it didn't feel like a mistake. It's always issues like this, where certain keys don't have the value you expect. Or capitalization becomes an issue. Or modifier keys get in the way. Or god forbid your user has a keyboard with a weird layout or does chording and the API just completely gives up. As ugly as the keyCode/which APIs are, they work. I've never had an issue with them.

kps 3y ago
`keyCode` are just raw Windows codes, which are a mess if you ever stray from Windows or US English. `VK_A` does not necessarily correspond to an ‘a’ and does not necessarily correspond to the same position as A on a US keyboard — in general there is nothing you can reliably say about it. `code` is useful for key positions, e.g. for WASD movement in a game. `key` is useful as the interpretation of a key, but primarily for non-text keys, since IMEs and virtual keyboards mean that text does not necessarily correspond directly to keys.

notresidenter 3y ago

I see more and more website use multiple inputs with JavaScript to handle automatically moving from one to the other for OTP codes, including GitHub. It's always buggy because the devs reimplement basic navigation (focus, deletion, arrow keys, etc.) and it turns out that stuff is hard to get right, so they get it wrong. Often, just typing too fast breaks those inputs (<https://github.com/login/device/ https://github.com/login/device/> for example). A simple input is much better, even at the cost of a UI that is slightly more ambigous for the user on desktop (on mobile, there's a bagillion things to make inputting OTP codes easy).

haolez 3y ago
Yeah, I think basic input with some magic when using "paste" from different source formats is the way to go.

eviks 3y ago

You could use listening to keys to make input more ergonomic: for example, allowing uio jkl m,. to be used as a keypad so you don't need to move your hand to the actual keypad. Or you can break actual keypads.

vel0city 3y ago
I personally never really cared for this setup, as on most keyboards that pattern is staggered and tilted while trying to emulate the straight number pad layout. The straight lines of the number pad are kind of the whole point to me for having a separate number pad area. Meanwhile all the numbers are still there on the regular keyboard just one row higher than you're normally typing. Plus, for a lot of typing a typist is already pressing the symbols on the number row anyways, so it's not like a typist is having to stretch to locations they're not normally pressing anyways. I'm not an accountant or mathematician or whatever so I tend to eschew number pads, so I'm probably a bit biased.
- eviks 3y ago
  > it's not like a typist is having to stretch to locations they're not normally pressing anyways. But they have to stretch, that's the issue, why do something unergonomic when you can do it better? On phones you have numpad input for the same reason - it's more convenient than the "familiar" horizontal keys > straight lines of the number pad are kind of the whole point to me for having a separate number pad area. But your fingers aren't straight, so that's also suboptimal. On the other hand you don't need to move your hand off home row and can also add more convenient backspace for error correction
  - vel0city 3y ago
    > But they have to stretch People already routinely type at least !, @, and $ often enough and it doesn't seem to be that big of a deal. > On phones you have numpad input for the same reason Yes, a straight grid of numbers for touchscreens not one heavily skewed to the side. Also, the number pad keyboard means larger hitboxes for numbers to type them faster. There's also no real "home row" on a phone keyboard. Look, if it makes you happy, do it. I'm just suggesting that to me its not really that much better than just pressing the keys that are practically always there on any regular keyboard. I'd personally just rather get better at pressing the number row keys instead of ensuring I'm on a keyboard or OS configuration to allow me to have some non-standard numberpad layer on the keyboard.

thesuitonym 3y ago

I really hate how modern developers try to reinvent forms. They always, always get it worse than the basic OS/HTML forms we've had for decades. Those dead stupid, simple forms were highly accessible, very performant, and easy to understand. It seems like forgotten information, but all of these computer interfaces that were invented in the 80s and 90s were built by doctorate level professionals who spent years thinking about these things. Why do all these bozos who took a six month code boot camp (or at best, finished a four year degree with a 2.9 GPA) think the ten minutes they spent thinking about it lead to some brilliant insight?

cqqxo4zV46cp 3y ago
I work with a lot of “doctorate-level professionals”. They are as flawed as everyone else. You took “don’t reimplement the browser”, something that is generally incredibly true, and cargo-culted it into placing some old farts on a pedestal just because they were there ‘first’.
- kunley 3y ago
  That's still an anecdotal evidence (that you in particular find them flawed) against a common sense.
- thesuitonym 3y ago
  You're right that they're as flawed as anyone else, but the point still stands that they spent years studying these problems. Years that modern developers, especially front end developers just don't have. I'm not saying these ideas shouldn't be revisited, but if you're going to revisit them, do it at an academic institute, where you can spend time figuring out the problems, not at your commercial job where you have to ship next week, no matter how broken it is.
  - Bockit 3y ago
    What’s special about front-end developers here?

dmitrygr 3y ago

We have forgotten that the browser was meant to be the user's agent

gspencley 3y ago

> Perhaps developers need to test on something other than MacBooks? This. So much this. I've gotten down-voted in the past for being really harsh on Macs, this is because I've worked places where the company would only issue MacBooks to its developers, and requests for non-Macs were denied by a blanket policy. So I kind of hold a grudge that's more fairly directed at the companies rather than Apple (but still, Apple's "our way or the highway" approach is antithetical to my way of interacting with computers). These company policies not only affect developer productivity when your engineers have decades of experience training themselves to be productive on their non-Mac system of choice, but it gets so much dumber when your company officially supports non-Mac-using users.

wodenokoto 3y ago
Isn’t the reverse just as stupid? Like, my company only dishes out Dells. I’m harsh on dell, but it’s not because of a company supplier contract.
- OJFord 3y ago
  The non-stupid reverse would be not to deny the requests for non-macs? So you'd have a mix of Dell Inspirons (or whatever) and MacBooks according to what was requested; some Edge users, some Chrome/Firefox but on Windows or Linux users, etc.
- gspencley 3y ago
  Well, yeah. For the productivity reason it's weird to tell engineers that they must use either a PC or Mac (and forget blanket "PC", if you're most productive on Linux or FreeBSD then ideally engineers can use those). The one rationale that makes sense to me when it comes to restricting choice to a certain degree is the ability for IT to remote-wipe if necessary. How important that is will depend on context. At my current place of work, most company data is accessed through various web applications so if the computer were compromised, there is no sensitive data kept locally that would require wiping. Though I suppose it could be argued that browser caches could be sensitive, and even if you couldn't sign on to those web apps, due to MFA, an attacker could still get information about procedures and tech used that would get them closer. But if they're using JAMF or something they can at least support Windows and Mac. The only other reason that I can think of that a company would have such a policy is economic... but lost productivity and user frustration is a hidden cost, so how real the economic advantages of standardizing are is something I question.

mrozbarry 3y ago

My general philosophy on this is clients will find ways to circumvent literally any special validation you are doing because they are vaguely in charge of their browser. Definitely use html form types, input, and pattern to attempt to ensure the user can't just do something wrong, but the backend needs to be the authority on what is actually valid. I like this unix style "strings as the universal data type" idea - it's not about how it happens, it's about the output. I honestly can't comprehend how something thought it was better to do `const validKeys = [NUMPAD_1, NUMPAD_2, ...];` and not `const validCharacters = '01234567890';`.

8organicbits 3y ago

This sort of complexity is a major reason I've been moving in the direction of dropping Javascript on sites I build. My last web app only used 4 lines of JS for dismissing messages. Django SSR, templates, forms, and plain HTML work in extremely predictable ways. It's much easier to reason about and test plain HTML.

deleted 3y ago

[deleted]

kps 3y ago

Using `code` here is pure ineptitude. It represents the physical position of a key, and is only useful for things like games using WASD movement; the same physical key routinely maps to different inputs under different languages and layouts. And `code` might not be set at all for on-screen (e.g. phone) keyboards. And IMEs don't necessarily send key events at all.

kmfrk 3y ago

A small peeve that frustrates me to no end is when I want to enter some numbers in iOS, and the app gives me a qwerty keyboard interface instead of a numpad. Such a small thing, but it drives me up the wall.

lnxg33k1 3y ago

One great concept I find very useful is just fail, like this thing of not showing letters is just wasted work, it has all the potential to be stressful without adding any value, let the user type whatever they want, if the result match the expected value, go ahead, otherwise retry

moistness 3y ago

This is incredibly hard to figure out. It’s not common sense to never touch the field while the user is interacting with it. - do not prevent default - do not limit my input to the exact number of characters - do not listen to any event other than “blur” unless you’re updating another part of the UI in real time I really wish that browsers gave control back to the users, and I say this as a FE developer.

ryandrake 3y ago
> I really wish that browsers gave control back to the users Exactly this. Browsers have stopped doing their job as the "User's Agent" and instead are acting more in the interest of web developers. Consequently, developers now see the browser window as a limitless empty canvas that they can just do whatever they want in, regardless of the user's desires.

cruffle_duffle 3y ago

While we are bitching about crappy inputs on websites, I haven’t seen anybody mention a bug I see on some sites. If you autofill things, the websites validation code doesn’t get triggered and will act like you didn’t enter anything in the fields that got autofilled. It’s like they are explicitly waiting for keystroke events to trigger a “user entered something” and forgot to add an “OR $(shit is in the field)” to their conditional. As a result you have to go back to all the autofilled fields and type something to trigger their validation logic. Annoying….

grishka 3y ago

Another pet peeve of mine is that some websites would intercept Cmd+F to provide their own, usually inferior, version of search, and all browsers being complicit. I wish there was a setting that would prevent websites from overriding browser's own hotkeys.

account42 3y ago
More than a setting, maybe it's time we had a separate browser for websites without all these app features.

butz 3y ago

On the bright side, they did not force you to "enter" 2FA code using spinner from "number" input field.

vel0city 3y ago
I'm imagining a drop down with all values between 000000 and 999999. And they somehow override the ability to just type into it to jump to the right value, you need to find it. And the list is unordered and randomized every page load.
- BizarroLand 3y ago
  How about a 6 digit RNG, click to get a number, if it's your number, then you click submit, otherwise re-roll. Of course, your 2FA updates every 30 seconds so hurry.
  - vel0city 3y ago
    Obviously, you'd want to add some anti-spam cooldowns to the number generator as well. To prevent abuse, of course.

deleted 3y ago

[deleted]

mrweasel 3y ago

On a similar note, the Danish government issues ID system doesn't work well with password managers. If the password managers fill in your username, you need to hit space to unlock the sign-in button. The password field, while it does support copy-paste, somehow manages to lock out password managers, so you need to open the password manager, copy your password and then paste (for some reason that field doesn't have the "forget to unlock sign-in" on paste feature.

gloosx 3y ago

Clearly the dev responsible for the input made a mistake, but why does it extrapolate into that javascript hatred? Like, before javascript is was impossible to make a mistake? The whole web was a perfect place without an issue?

ninkendo 3y ago
Before JavaScript it was impossible to make this mistake, yes. The web was originally envisioned such that the hypertext described the form elements and the browser was responsible for the UI behavior. JavaScript brought the idea of a Turing complete language you can use to completely define the behavior of your UI, and with that it brought the possibility of an infinite number of mistakes that devs can make. JavaScript violates the rule of least power in this regard: https://en.m.wikipedia.org/wiki/Rule_of_least_power https://en.m.wikipedia.org/wiki/Rule_of_least_power
- gloosx 3y ago
  > Before JavaScript it was impossible to make this mistake Before JavaScript it was impossible to even implement such functionality on the client side... There was no "number" input before HTML5 spec which came out in 2008, and was adopting for 6 years before finally becoming a recommendation in 2014. You had to let user put any text in the input and do the validation on the backend, which had the same Turing complete language running letting you make any mistakes you want. Rule of least power is just a design principle, and it could not hold as an axiom of good design for the web, because when the least power becomes not enough power, it takes years for the adoption of new powers needed – that's why JavaScript exists in the first place.

letsSpy 3y ago

also, let me paste my email in signup forms and don't ask me for it twice

dramm 3y ago

Thanks. I enjoyed the hour I spent reading about Alphonse Chapanis.

chrismorgan 3y ago

> There are two ways to do this - a right way and a wrong way - using KeyboardEvent. I reject this strongly: they’re both wrong. It’s not reasonable to control this via a KeyboardEvent at all. If you want to do this sort of thing, you should only manipulate in real-time based on the input’s value and selection, triggering on 'input' events when !event.isComposing. Otherwise, you will break things for some users. Also, you should very, very strongly consider not manipulating the field contents, but only validating (and somewhat relaxed masking at that). The web just doesn’t give good, robust primitives for input masking.