-
Notifications
You must be signed in to change notification settings - Fork 27.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ExtensionHost debugging: debug action window disappears briefly #43516
Comments
This is happening due to how we are connecting to the extension host. |
We need to understand this and then we should really make this robust enough so that it does not result in this behaviour on just one platform. We can investigate this together... |
This happens now on all platforms. |
With the introduction of the "postDebugTask" the "bigger breakage" has now arrived: with this bug "postDebugTask" is no longer symmetric to "preLauchTask". |
@isidorn what is the event that makes you turn down the debug session? |
@weinand I will now write down the exact ordering of events and what is going on so we can analyize on what is best to be done here. |
Extension launched
Extension restart from first window
Extension restart by pressing reload in the second window
Notice that in this case I am not getting any event that the debugger has exited and I believe that is the reason why I choose to always end and start on broadcast Extension is ended from first window
Extension is ended by clicking close on the second window
|
We also need to be aware of that timing on different machines can be different. I remember that sometimes I would first get the broadcast and only then the adapter exit event and this would screw up my logic, however the current approach is also not error prone to this it seems. So from this analysis the main issue is the reload in the second window which only sends the |
The issue at hand is only item 2. under "Extension launched": You kill the process that you've just created because you do not know that the attach is not a re-attach. Does it help if you introduce a flag ("somewhere") that tells you whether this is the first attach (which does not require to kill anything). If you cannot find a place (i.e. object) where to store that flag, could you look at the events you receive to find out whether it is a restart? |
While verifying this I noticed another issue: #48442 |
Nice diagram, we need a couple poster-sized prints! |
The fix worked for me when running out of source. Moving back to Isidor. |
@weinand thanks for investigating. I will look into this |
Thanks to @isidorn's perseverance we now understand why the new fix in node-debug2 was working for me: I still had the original fix for this issue in my workspace. And the new fix was relying on the old fix (but I wasn't aware of this). |
The fix resulted in #48955, thus reverting and assigning to May. |
I have fixed this by not restarting the whole DebugSession, but only ending the rawSession and starting a new session. And since DebugSession now survives a reaatach there are no more flashes. Debug an extension and
|
Steps:
Observe:
Debug action bar disappears and comes back.
It looks like an additional short-living session is created on startup.
I do not see this behaviour on macOS and linux.
The text was updated successfully, but these errors were encountered: