Typing set in CB and accepting it quickly is putting at or select_columns in the node
#6908
Comments
|
Even after #6875 it still reproducible, however, I'm not able to put The strange thing is, that when typing slowly, at no point |
|
Michael Mauderer reports a new STANDUP for yesterday (2023-06-06): Progress: Was unable to test the fix for #6724 locally and this was taking too much time. So now I will wait for the merged PR to be available in a cloud release before following up. Started investigating the wrong selection of items from the CB when typing fast. It should be finished by 2023-06-09. Next Day: Next day I will be working on the #6908 task. Find root cause of the wrong selection. |
|
Michael Mauderer reports a new STANDUP for yesterday (2023-06-07): Progress: Investigating the wrong selection of items from the CB when typing fast. So far, I've found that there is an additional update to sorting/filtering to the CB content between the confirmation of selection and the selection being applied, followed by an async update notification. But due to the architecture and size of the CB it is difficult to trace the events and the state of the CB. It should be finished by 2023-06-09. Next Day: Next day I will be working on the #6908 task. Find root cause of the wrong selection. |
|
Michael Mauderer reports a new STANDUP for today (2023-06-08): Progress: Investigating the wrong selection of items from the CB when typing fast. Seems that the updates sorting is unrelated to the issue, and instead, the actual identity of the emitted selection changes depending on the timing of the CB selection. Tracing the changes to the selected item and how it is generated and changed in the time after the selection is made. It should be finished by 2023-06-09. Next Day: Next day I will be working on the #6908 task. Find root cause of the wrong selection. |
|
Michael Mauderer reports a new 🔴 DELAY for today (2023-06-12): Summary: There is 4 days delay in implementation of the Typing 2 days weekend + 2 days delay. Delay Cause: Issue was trickier to debug than expected due to the complexity of component browser and asynchronous update interactions. In this case, debugging also altered the observable events and was hiding/altering the issue in some circumstances. Possible solutions: Better tooling for debugging FRP events throughout the application, e.g., full logging to capture all state + tool that can filter what is shown. |
|
Michael Mauderer reports a new STANDUP for the provided date (2023-06-09): Progress: Found the events that caused the difference. It appears that we (a) rely on some default values of the Next Day: Next day I will be working on the #6908 task. Find fix for root cause of the wrong selection. |
|
Michael Mauderer reports a new STANDUP for yesterday (2023-06-13): Progress: After some more failing ideas and more debugging, I found the working solution based on changed delay times and additional refresh on input editing. It should be finished by 2023-06-13. Next Day: Next day I will be working on the #6908 task. Open PR and start next task. |
|
Michael Mauderer reports a new STANDUP for the provided date (2023-06-12): Progress: Tried several solutions that did not work, but after talking to Adam we have a more promising approach that I will try next. It should be finished by 2023-06-13. Next Day: Next day I will be working on the #6908 task. Implement working solution for wrong selection. |
|
Michael Mauderer reports a new 🔴 DELAY for today (2023-06-15): Summary: There is 2 days delay in implementation of the Typing Delay Cause: Turns out the fix I had was not actually correct and only working by mistake. New fix needs to be investigated and implemented. |
|
Michael Mauderer reports a new STANDUP for yesterday (2023-06-14): Progress: Implemented a first fix after discussing with Adam. But it turns out this fix is not quite right, while it does seem to fix the behaviour, after some more examination, it does so only coincidentally. Further investigation is needed to find the correct solution. It should be finished by 2023-06-15. Next Day: Next day I will be working on the #6908 task. Implement working solution for wrong selection. |
|
Michael Mauderer reports a new STANDUP for yesterday (2023-06-15): Progress: Found the correct solution. It was related to the order that events are processed when committing the node and correct handling of the cached text changes. Correct implementation is ready for PR. It should be finished by 2023-06-15. Next Day: Next day I will be working on the #6908 task. Start next task. |
Fixes #6908 Fast typing leads to a race condition where the end of the node editing can happen where the state of the CB is not caught up yet. This leads to two issues: 1. The wrong selection is made, as the View of the Component Browser has not been updated yet, but the selection from there is used to determine how the node is created. 2. Processing of the keys is aborted early, while still waiting for additional key input. This is now fixed. https://github.com/enso-org/enso/assets/1428930/dce82bb3-1c25-4a67-988a-d74469dc8fcd
Discord username
No response
What type of issue is this?
Intermittent – Occurring irregularly
Is this issue blocking you from using Enso?
Is this a regression?
What issue are you facing?
set.to.at.mov
Expected behaviour
node should contain method that was typed
How we can reproduce it?
setand pressenterquicklyScreenshots or screencasts
No response
Logs
No response
Enso Version
nightly 31.05
Browser or standalone distribution
Standalone distribution (local project)
Browser Version or standalone distribution
standalone
Operating System
MacOS
Operating System Version
No response
Hardware you are using
No response
The text was updated successfully, but these errors were encountered: