You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 20, 2020. It is now read-only.
I made an error in DesktopDragDropClientWayland::OnDragDrop that I did not notice until after the code got committed. Kalyan noticed a race condition and asked me to fix it. I added a comment "Unlikely case" explaining the problem, and started writing some code to fix it, but promptly forgot; it got committed unfinished, oops. So the code under that comment basically does nothing. We need to add a way to wait until all the data has been received, and then call delegate_->OnPerformDrop, otherwise there is a race that could cause drops to fail if they contain huge amounts of data, or if the I/O is horrifically slow.
Ideally we would also add a test for this by faking the order that events are received in. desktop_drag_drop_client_aurax11_unittest.cc should provide inspiration.
(Not planning to fix this in the near future, I'm afraid; sorry for the error. Fortunately it's probably low-priority, as I doubt it would occur in practice.)
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I made an error in DesktopDragDropClientWayland::OnDragDrop that I did not notice until after the code got committed. Kalyan noticed a race condition and asked me to fix it. I added a comment "Unlikely case" explaining the problem, and started writing some code to fix it, but promptly forgot; it got committed unfinished, oops. So the code under that comment basically does nothing. We need to add a way to wait until all the data has been received, and then call delegate_->OnPerformDrop, otherwise there is a race that could cause drops to fail if they contain huge amounts of data, or if the I/O is horrifically slow.
Ideally we would also add a test for this by faking the order that events are received in. desktop_drag_drop_client_aurax11_unittest.cc should provide inspiration.
(Not planning to fix this in the near future, I'm afraid; sorry for the error. Fortunately it's probably low-priority, as I doubt it would occur in practice.)
The text was updated successfully, but these errors were encountered: