HackStudio: Opening multiple files simultaneously makes it freak out #16263
Comments
|
Started analyzing the code couple of hours ago, a simple solution to this in my opinion would be to disable multi-selection inside the treeview? Else I'm pretty sure there's a problem with how the serenity/Userland/DevTools/HackStudio/HackStudioWidget.cpp Lines 589 to 599 in 6dbe7b0 |
|
At the end I've found out that serenity/Userland/DevTools/HackStudio/HackStudioWidget.cpp Lines 771 to 777 in 69f41eb Don't really know its purpose (not even after trying to read the function) so I'm not sure whether removing the call is the best fix. |
That sounds like just papering over the issue, I think it's valid to want to open multiple files at once. |
|
@osamu-kj I think you're close to a fix (I've not tested this), but I think the issue is probably in the deferred invoke here, that sets the current editor: You probably want to debounce setting the active editor (so it only ends up switching to the last file), you might be able to do something with |
|
hmm, I'm missing out on what some of the code over there does.. |
Wanted to look at this one since it looked quite funny :^) This seemed to come from an awkward interplay of deferred callbacks and doubly deferred callbacks! This is fixed here my simply avoiding making some of these calls in the first place (as they were unnecessary anyway). But the infinite loop came from something like this: set_tab(A) // Active tab A defer set_tab(A) // from on_change() set_tab(B) // Active tab B defer set_tab(B) // from on_change() -> Deferred invokes run: set_tab(A) // Tab changed from B -> A defer set_tab(A) // fire on_change() -- queue new defer set_tab(B) // Tab changed from A -> B defer set_tab(B) // fire on_change() -- queue new defer :infinteyakloop: Fixes SerenityOS#16263
Wanted to look at this one since it looked quite funny :^) This seemed to come from an awkward interplay of deferred callbacks and doubly deferred callbacks! This is fixed here by simply avoiding making some of these calls in the first place (as they were unnecessary anyway). But the infinite loop came from something like this: set_tab(A) // Active tab A defer set_tab(A) // from on_change() set_tab(B) // Active tab B defer set_tab(B) // from on_change() -> Deferred invokes run: set_tab(A) // Tab changed from B -> A defer set_tab(A) // fire on_change() -- queue new defer set_tab(B) // Tab changed from A -> B defer set_tab(B) // fire on_change() -- queue new defer :infinteyakloop: Fixes SerenityOS#16263
Wanted to look at this one since it looked quite funny :^) This seemed to come from an awkward interplay of deferred callbacks and doubly deferred callbacks! This is fixed here by simply avoiding making some of these calls in the first place (as they were unnecessary anyway). But the infinite loop came from something like this: set_tab(A) // Active tab A defer set_tab(A) // from on_change() set_tab(B) // Active tab B defer set_tab(B) // from on_change() -> Deferred invokes run: set_tab(A) // Tab changed from B -> A defer set_tab(A) // fire on_change() -- queue new defer set_tab(B) // Tab changed from A -> B defer set_tab(B) // fire on_change() -- queue new defer :infinteyakloop: Fixes SerenityOS#16263
Wanted to look at this one since it looked quite funny :^) This seemed to come from an awkward interplay of deferred callbacks and doubly deferred callbacks. This is now fixed with a workaround to prevent `current_editor().set_focus(true)' from updating the editor if the current editor changed by the time the (deferred) focus event fires. But the infinite loop came from something like this: set_tab(A) // Active tab A defer set_tab(A) // from on_change() set_tab(B) // Active tab B defer set_tab(B) // from on_change() -> Deferred invokes run: set_tab(A) // Tab changed from B -> A defer set_tab(A) // fire on_change() -- queue new defer set_tab(B) // Tab changed from A -> B defer set_tab(B) // fire on_change() -- queue new defer :infinteyakloop: Fixes SerenityOS#16263
Wanted to look at this one since it looked quite funny :^) This seemed to come from an awkward interplay of deferred callbacks and doubly deferred callbacks. This is now fixed with a workaround to prevent `current_editor().set_focus(true)' from updating the editor if the current editor changed by the time the (deferred) focus event fires. But the infinite loop came from something like this: set_tab(A) // Active tab A defer set_tab(A) // from on_change() set_tab(B) // Active tab B defer set_tab(B) // from on_change() -> Deferred invokes run: set_tab(A) // Tab changed from B -> A defer set_tab(A) // fire on_change() -- queue new defer set_tab(B) // Tab changed from A -> B defer set_tab(B) // fire on_change() -- queue new defer :infinteyakloop: Fixes SerenityOS#16263
To reproduce:
The text was updated successfully, but these errors were encountered: