Skip to content

fix: prevent stuck "Loading..." hover#1394

Merged
rubenporras merged 1 commit intoeclipse-lsp4e:mainfrom
sebthom:issue-1388
Nov 18, 2025
Merged

fix: prevent stuck "Loading..." hover#1394
rubenporras merged 1 commit intoeclipse-lsp4e:mainfrom
sebthom:issue-1388

Conversation

@sebthom
Copy link
Copy Markdown
Member

@sebthom sebthom commented Nov 13, 2025

Addresses second issue raised in #1388

@sebthom sebthom force-pushed the issue-1388 branch 2 times, most recently from a9bedaf to dac2d52 Compare November 13, 2025 14:12
});
})
// Ensure the placeholder is not stuck if LS never replies
.completeOnTimeout(null, GET_HOVER_CONTENT_TIMEOUT_SECONDS, TimeUnit.SECONDS);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not convinced that closing the pop-up is a good thing to. Is it actually a UI problem that the UI shows loading if the server is stuck? I would rather say that is a problem for the server, as the user can always dimiss the dialog when he is tired of waiting by moving away the cursor, typing, closing the editor...

If the problem is that it appears that the UI is stuck, could we maybe have some dots appears one by one using a timer and the cycling to one dot after a bunch of those?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I cannot reproduce the issue that @FlorianKroiss described. So I just added this guard. Maybe we should cancel the initiateHoverRequest after some time and swap out the "Loading..." message by something else?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The LS is NOT stuck in my case. I think the problem is that a null value that is returned from the future in AsyncHtmlHoverInput is handled incorrectly.

If I replace the dispose() for this case with super.setInput("Nothing to see"); it is properly updated:

} else {
// No content from LS; hide placeholder
dispose();
}

image

The call to dispose() actually disposes the Shell, which is probably not intended?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@FlorianKroiss I replaced the dispose calls with setText(""), can you please give this snapshot build a try: https://github.com/eclipse-lsp4e/lsp4e/actions/runs/19375743759/artifacts/4572560568

@sebthom sebthom changed the title fix: prevent stuck "Loading..." hover by timing out after 5s fix: prevent stuck "Loading..." hover Nov 14, 2025
Copy link
Copy Markdown
Contributor

@FlorianKroiss FlorianKroiss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@rubenporras
Copy link
Copy Markdown
Contributor

@sebthom , if we can get this one finished tomorrow, I would create another release.

@sebthom
Copy link
Copy Markdown
Member Author

sebthom commented Nov 17, 2025

I think this is ready to be merged.

} else {
// No content from LS; hide placeholder
dispose();
super.setInput(""); //$NON-NLS-1$
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I understand this one and I also think it is the best thing to do. My understanding is: the text "Loading..." will be replaced with the empty string, and the content will be available until the user dismisses it. Correct?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct

if (ex != null) {
LanguageServerPlugin.logError(ex);
dispose();
super.setInput(""); //$NON-NLS-1$
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure about this one. In case of an exception, should we not close the text hover? Or maybe use ex.getMessage() and set that to something like "An exception has happened: ..."

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed it to show the error message

@rubenporras
Copy link
Copy Markdown
Contributor

I think this is ready to be merged.

Sorry, my mistake, I have not published my review before. I have done it now. I will read your answers tomorrow. Have a nice evening.

@rubenporras rubenporras merged commit ed07757 into eclipse-lsp4e:main Nov 18, 2025
10 checks passed
@sebthom sebthom deleted the issue-1388 branch November 18, 2025 18:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants