-
Notifications
You must be signed in to change notification settings - Fork 13
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
Adding a step can take more than 12 seconds #132
Comments
so would mean that in VS Code, it is awaiting for the previosu requests to finish but not on OperateFirst? |
sounds like the difference is that in VS Code, the contextual catalog is displayed before it has finished to load the images, in Chrome or Firefox, the catalog is taking more time to be displayed, it si waiting for the image to be displayed. Consequently when clicking next on the element to add the step, it is immediate and no more need to wait for it |
Updated the mime type for the 3 images, these request are now faster (retrieving from cache) but the other request on actimq-action?namespace=default remains slow |
sounds unrelated to the request itself given that I reproduce the same kind of delay trying to close the contextual catalog which is triggering no request to the server at all. see #130 (comment) |
I do not reproduce in Chromium 102.0.5005.0 which is the closest that I found than the one embedded in VS Code 1.75.1 (102.0.5005.194 ) |
fixes KaotoIO#166 fixes KaotoIO#158 fixes KaotoIO#145 fixes KaotoIO#132 Signed-off-by: Aurélien Pupier <[email protected]>
fixes #166 fixes #158 fixes #145 fixes #132 Signed-off-by: Aurélien Pupier <[email protected]>
seems to be since backend 0.6.2 (to be confirmed)
The text was updated successfully, but these errors were encountered: