6 ms·

This is bad but it's not unusual. There are similar issues in Firefox and Windows. Nobody gets UI asynchrony right. There are race conditions in everything. It'

This is bad but it's not unusual. There are similar issues in Firefox and Windows. Nobody gets UI asynchrony right. There are race conditions in everything. It's particularly noticeable with a slow computer.

danaliv 6y ago
I promise you people have gotten this right. I have a 198? Mac Plus on my desk that I can boot up and do this on and it will work properly. I’m having trouble even imagining the insane event-processing architecture that results in keystrokes being processed out of order. Edit: Alright, alright, forget the old computer. My new ones get it right too. All of which is a red herring, because the point is this behavior is ridiculous and never should’ve shipped.
- ivanbakel 6y ago
  >I’m having trouble even imagining the insane event-processing architecture that results in keystrokes being processed out of order. It's relatively simple: the picker executes file-opening asynchronously, and only checks which file was selected at some indeterminate point after enter is pressed. In the meantime, the down arrow input in the main GUI changes the selection. The keypresses are always in order. Whether or not that's the correct decision, it's not an inconceivable design. That example is probably one of the only times it would matter, since you would need async code that cares about some part of the file picker state.
  - ballenf 6y ago
    Why wouldn't the <enter> key interrupt or freeze the keypress queue? I don't think you need some advanced async logic to get this right. The only potential downside would be if people expected to be able to cancel the <enter> action. But that would be unusual, I think.
    - ivanbakel 6y ago
      As a rule of thumb: if you ever ask "why not", and the alternative you're proposing is more complicated - that is normally why not. Lots of UI/UX bugs can simply be attributed to the programmer taking the most simple possible design. In this case, the async logic is not advanced. In fact, I'm willing to bet that this is what happened: at first, the file-opening was synchronous in the GUI. People complained that opening certain files locked up the file picker, so a developer sticks the file-opening code in a background thread. This produces the above bug, without complicating the input design - in fact, preventing the bug requires making additional changes to the code in some way.
      - ballenf 6y ago
        Thanks that makes total sense. And a good rule of thumb for me to remember.
    - toast0 6y ago
      You can't do work on the UI thread, it'll block the UI! With only half a /s
  - freeone3000 6y ago
    Why does the enter keypress save the relative index instead of the actual target of the action? Even Windows gets this one right.
  - userbinator 6y ago
    To sound like Linus Torvalds, "that's braindead stupid!" I have never looked at the code in question, but it almost sounds like the developers went out of their way to create these ridiculous bugs, because the simplest solution definitely would not have something like that happen: The handler for Enter gets the current selection (which will definitely be the correct one) and opens it. The actual opening can be slow, so that can be done asynchronously. But to interpret "Enter opens the current selection" as anything other than the current selection at the time the Enter key event was received is definitely in the realm of rookie mistake if not worse. If getting the current selection of a UI control somehow needs to be done asynchronously, then something is seriously wrong. As a long-time Win32 programmer, the manifestations of these bugs are definitely hard to conceive.
    - stelonix 6y ago
      This is an issue with X11 which I don't know exactly where it comes from and what causes it. Yes, it has to do with the async nature of it all and I agree it's stupid and it's a miracle the desktop even works. Over time, I've been wondering if Windows dodges this simply by having syscalls that interface with window procedures while Xorg deals horribly with it by being pure userland. Another issue is, there's no mapping of pid <-> X11 window. It's simply impossible with the current design of client-server.
      - account42 6y ago
        > This is an issue with X11 What makes you think this is the case? X11 has an ordered event queue and there is no reason an application can't process the keystrokes in the correct order. > Another issue is, there's no mapping of pid <-> X11 window. It's simply impossible with the current design of client-server. What do you need this for? There is _NET_WM_PID [0] which can be set by clients. [0] https://specifications.freedesktop.org/wm-spec/wm-spec-1.3.html#idm45760170745312 https://specifications.freedesktop.org/wm-spec/wm-spec-1.3.h...
        stelonix 6y ago
        _NET_WM_PID is optional, some clients do not set it and even then afaik the server doesn't do any sanity check and the client can set it to anything, making it inherently insecure. This is not good design. > What makes you think this is the case? Many other ways in which async behavior happens on X11, on any machine I've tried, with the mouse cursor lagging to register a click event, for example.
  - thaumasiotes 6y ago
    > Whether or not that's the correct decision, it's not an inconceivable design. I'm having trouble with the part of the design where we recognize that a file is selected (such that pressing <enter> causes a file to open), see the <enter> keypress, and then fire an event saying "open any file, whichever one you feel like" as opposed to "open this file right here, the one we can see is selected". If, as you maintain, the keystrokes are processed in order, then at the time <enter> is processed, we specifically take notice of which file is selected. (Because, as I said above, we only know that <enter> should open a file at all because we see that a file is selected.) We fire the file-opening event after that. This isn't a mistake we can make by accident; we'd have to be making it on purpose. I can see where the assumption that the keystrokes are being reordered comes from; it's much less insane than what you're proposing.
    - ivanbakel 6y ago
      Because the event says "open the currently selected file", not "open this file because it is the selected one". If the event is processed asynchronously w.r.t. other events which can modify the selection, you can get buggy behaviour. I don't find such a design that surprising. If you like simplicity, you would be tempted to go for it, because it doesn't involve duplicating data (namely, the selected filepath) between the main GUI state and the event handler for opening the selected file. If you're writing in a memory-managing language like C, it's even more tempting - by not copying data, you don't risk forgetting to free it later.
      - polynomial 6y ago
        This is a great example of where OOP and FP necessarily part ways.
        FridgeSeal 6y ago
        That’s a cool idea, how so?
        polynomial 6y ago
  - imtringued 6y ago
    >Whether or not that's the correct decision, it's not an inconceivable design. It's easy to imagine. Someone kept a variable for the current selection and instead of copying it during the enter event they just read it when the delayed action happens. It often takes time for a second window to open or a page to load. If that new window references the current selection you are going to run into bugs. It's a design that has caused many video game exploits. You can do impossible things like disassemble a Fat man barrel and put it on a pistol in Fallout. You will get a rocket launcher that has the fire rate of a pistol except it shoots nukes and only uses bullets as ammo.
- buckminster 6y ago
  All old computers get it right. They are not doing UI asynchrony. It's a fairly recent problem.
  - danaliv 6y ago
    My new computers get this right too. This is a design flaw.
  - mkl 6y ago
    Keyboard maybe. That same old Mac probably processes mouse events out of order: when it was being slow you could click on something then move the mouse somewhere else, and it would click the new place instead.
- viraptor 6y ago
  That Mac cannot multithread the UI interactions. It doesn't have to be a keystroke processing issue. It can be "hey window parent, I've got your result in my properties, pick it up" which doesn't get processed before the next event changes the related property. It's almost a classic TOCTOU issue.
  - deleted 6y ago
    [deleted]
  - edoceo 6y ago
    Time of check, Time of Use https://en.m.wikipedia.org/wiki/Time-of-check_to_time-of-use https://en.m.wikipedia.org/wiki/Time-of-check_to_time-of-use
- masswerk 6y ago
  However, the Mac was about the only system getting this right by rigorously prioritizing UI events on the system level. (Which is also, why applications like Photoshop on Windows weren't a viable option for professional users for some time, until hardware became faster. How do you draw or paint, if the events representing your gestures are not synchronized, as they are subject to system load?)
jfoster 6y ago
It's akin to typing and having the characters appear out of order, isn't it? Are those particular keys more difficult to process?
- efreak 6y ago
  Only if each key has its own function to process that keystroke, and some keystrokes had to do more processing and thus take more time about it. Selecting an item in a list view is a fast, simple process; what happens after that isn't up to the list view anymore.
Ndymium 6y ago
LibreOffice had (has?) a similar strange race condition when typing. When the computer was acting slow and LibreOffice Writer was lagging, the Finnish layout's characters äöå would jump to the front of the typing queue somehow. So if I typed "menkäämme", I might get "äämenkmme" when LibreOffice finally renders the typed text. I don't know if it still occurs but it was really annoying and I always wondered how on earth it could happen.

danaliv 6y ago

I promise you people have gotten this right. I have a 198? Mac Plus on my desk that I can boot up and do this on and it will work properly. I’m having trouble even imagining the insane event-processing architecture that results in keystrokes being processed out of order. Edit: Alright, alright, forget the old computer. My new ones get it right too. All of which is a red herring, because the point is this behavior is ridiculous and never should’ve shipped.

ivanbakel 6y ago
>I’m having trouble even imagining the insane event-processing architecture that results in keystrokes being processed out of order. It's relatively simple: the picker executes file-opening asynchronously, and only checks which file was selected at some indeterminate point after enter is pressed. In the meantime, the down arrow input in the main GUI changes the selection. The keypresses are always in order. Whether or not that's the correct decision, it's not an inconceivable design. That example is probably one of the only times it would matter, since you would need async code that cares about some part of the file picker state.
- ballenf 6y ago
  Why wouldn't the <enter> key interrupt or freeze the keypress queue? I don't think you need some advanced async logic to get this right. The only potential downside would be if people expected to be able to cancel the <enter> action. But that would be unusual, I think.
  - ivanbakel 6y ago
    As a rule of thumb: if you ever ask "why not", and the alternative you're proposing is more complicated - that is normally why not. Lots of UI/UX bugs can simply be attributed to the programmer taking the most simple possible design. In this case, the async logic is not advanced. In fact, I'm willing to bet that this is what happened: at first, the file-opening was synchronous in the GUI. People complained that opening certain files locked up the file picker, so a developer sticks the file-opening code in a background thread. This produces the above bug, without complicating the input design - in fact, preventing the bug requires making additional changes to the code in some way.
    - ballenf 6y ago
      Thanks that makes total sense. And a good rule of thumb for me to remember.
  - toast0 6y ago
    You can't do work on the UI thread, it'll block the UI! With only half a /s
- freeone3000 6y ago
  Why does the enter keypress save the relative index instead of the actual target of the action? Even Windows gets this one right.
- userbinator 6y ago
  To sound like Linus Torvalds, "that's braindead stupid!" I have never looked at the code in question, but it almost sounds like the developers went out of their way to create these ridiculous bugs, because the simplest solution definitely would not have something like that happen: The handler for Enter gets the current selection (which will definitely be the correct one) and opens it. The actual opening can be slow, so that can be done asynchronously. But to interpret "Enter opens the current selection" as anything other than the current selection at the time the Enter key event was received is definitely in the realm of rookie mistake if not worse. If getting the current selection of a UI control somehow needs to be done asynchronously, then something is seriously wrong. As a long-time Win32 programmer, the manifestations of these bugs are definitely hard to conceive.
  - stelonix 6y ago
    This is an issue with X11 which I don't know exactly where it comes from and what causes it. Yes, it has to do with the async nature of it all and I agree it's stupid and it's a miracle the desktop even works. Over time, I've been wondering if Windows dodges this simply by having syscalls that interface with window procedures while Xorg deals horribly with it by being pure userland. Another issue is, there's no mapping of pid <-> X11 window. It's simply impossible with the current design of client-server.
    - account42 6y ago
      > This is an issue with X11 What makes you think this is the case? X11 has an ordered event queue and there is no reason an application can't process the keystrokes in the correct order. > Another issue is, there's no mapping of pid <-> X11 window. It's simply impossible with the current design of client-server. What do you need this for? There is _NET_WM_PID [0] which can be set by clients. [0] https://specifications.freedesktop.org/wm-spec/wm-spec-1.3.html#idm45760170745312 https://specifications.freedesktop.org/wm-spec/wm-spec-1.3.h...
      - stelonix 6y ago
        _NET_WM_PID is optional, some clients do not set it and even then afaik the server doesn't do any sanity check and the client can set it to anything, making it inherently insecure. This is not good design. > What makes you think this is the case? Many other ways in which async behavior happens on X11, on any machine I've tried, with the mouse cursor lagging to register a click event, for example.
- thaumasiotes 6y ago
  > Whether or not that's the correct decision, it's not an inconceivable design. I'm having trouble with the part of the design where we recognize that a file is selected (such that pressing <enter> causes a file to open), see the <enter> keypress, and then fire an event saying "open any file, whichever one you feel like" as opposed to "open this file right here, the one we can see is selected". If, as you maintain, the keystrokes are processed in order, then at the time <enter> is processed, we specifically take notice of which file is selected. (Because, as I said above, we only know that <enter> should open a file at all because we see that a file is selected.) We fire the file-opening event after that. This isn't a mistake we can make by accident; we'd have to be making it on purpose. I can see where the assumption that the keystrokes are being reordered comes from; it's much less insane than what you're proposing.
  - ivanbakel 6y ago
    Because the event says "open the currently selected file", not "open this file because it is the selected one". If the event is processed asynchronously w.r.t. other events which can modify the selection, you can get buggy behaviour. I don't find such a design that surprising. If you like simplicity, you would be tempted to go for it, because it doesn't involve duplicating data (namely, the selected filepath) between the main GUI state and the event handler for opening the selected file. If you're writing in a memory-managing language like C, it's even more tempting - by not copying data, you don't risk forgetting to free it later.
    - polynomial 6y ago
      This is a great example of where OOP and FP necessarily part ways.
      - FridgeSeal 6y ago
        That’s a cool idea, how so?
        polynomial 6y ago
- imtringued 6y ago
  >Whether or not that's the correct decision, it's not an inconceivable design. It's easy to imagine. Someone kept a variable for the current selection and instead of copying it during the enter event they just read it when the delayed action happens. It often takes time for a second window to open or a page to load. If that new window references the current selection you are going to run into bugs. It's a design that has caused many video game exploits. You can do impossible things like disassemble a Fat man barrel and put it on a pistol in Fallout. You will get a rocket launcher that has the fire rate of a pistol except it shoots nukes and only uses bullets as ammo.
buckminster 6y ago
All old computers get it right. They are not doing UI asynchrony. It's a fairly recent problem.
- danaliv 6y ago
  My new computers get this right too. This is a design flaw.
- mkl 6y ago
  Keyboard maybe. That same old Mac probably processes mouse events out of order: when it was being slow you could click on something then move the mouse somewhere else, and it would click the new place instead.
viraptor 6y ago
That Mac cannot multithread the UI interactions. It doesn't have to be a keystroke processing issue. It can be "hey window parent, I've got your result in my properties, pick it up" which doesn't get processed before the next event changes the related property. It's almost a classic TOCTOU issue.
- deleted 6y ago
  [deleted]
- edoceo 6y ago
  Time of check, Time of Use https://en.m.wikipedia.org/wiki/Time-of-check_to_time-of-use https://en.m.wikipedia.org/wiki/Time-of-check_to_time-of-use
masswerk 6y ago
However, the Mac was about the only system getting this right by rigorously prioritizing UI events on the system level. (Which is also, why applications like Photoshop on Windows weren't a viable option for professional users for some time, until hardware became faster. How do you draw or paint, if the events representing your gestures are not synchronized, as they are subject to system load?)

jfoster 6y ago

It's akin to typing and having the characters appear out of order, isn't it? Are those particular keys more difficult to process?

efreak 6y ago
Only if each key has its own function to process that keystroke, and some keystrokes had to do more processing and thus take more time about it. Selecting an item in a list view is a fast, simple process; what happens after that isn't up to the list view anymore.

Ndymium 6y ago

LibreOffice had (has?) a similar strange race condition when typing. When the computer was acting slow and LibreOffice Writer was lagging, the Finnish layout's characters äöå would jump to the front of the typing queue somehow. So if I typed "menkäämme", I might get "äämenkmme" when LibreOffice finally renders the typed text. I don't know if it still occurs but it was really annoying and I always wondered how on earth it could happen.