Command "haskell.showDocumentation" not working

[oshyshko]

• Haskell extension 1.4.0
• haskell-language-server version: 1.1.0.0 (GHC: 8.10.4)
• VS Code 1.56.2
• macos 10.15.7
• GHC 8.10.4 (via Stackage lts-17.12)
• Stack 2.7.1

[sLite]

Same problem for me on OpenSuse Leap 15.2 with the same Extension, VS Code and GHC Version.

[pepeiborra]

This old ghcide PR would probably fix it, if someone wants to investigate: haskell/ghcide#861

[berberman]

I found the links produced by ghcide were correct, and downgrade vscode to 1.55.2 could fix the issue. Perhaps some changes in vscode April 2021 release broke this feature.

[eirikm]

I can confirm that this is working with:

Haskell extension 1.4.0
haskell-language-server version: 1.1.0.0 (GHC: 8.10.4)
VS Code 1.54.1
macos 10.15.7
GHC 8.10.4 (via Stackage lts-17.13)
Stack 2.7.1

[jneira]

Ok, thanks for the diagnosis, i am moving it to the vscode repo again

[skress]

The problem seems to be the iframe that is used to include the documentation into the webview panel.

See microsoft/vscode#123766 (comment) which states that this case is not supported anymore and microsoft/vscode#121479 for a bit more context.

[mjhoy]

Any ideas on this one? I find this was a pretty useful feature.

[jneira]

From microsoft/vscode#121479 (comment):

As far as I know, service worker do not see requests for top level iframe pages (inspector.html in your example). If you are loading local content into an iframe inside a webview, chances are that you should probably just load that content into the webview itself and skip the iframe (and all of the extra stumbling blocks it adds)

Please try updating your extension to use a different approach that does not rely on loading iframe content with as a webview resource (content inside iframes that are on the same origin as the host webview should still go through the service worker)

It seems we have to replace the existing iframe (i've not checked it though)

[mjhoy]

I played around with this and couldn't really get the webview to render local documentation satisfactorily — it seems like you can't really have file:/// links to local resources, you need special vscode-resource: links. But I might be missing something.

I'm curious if a PR that simply changed the functionality to open the local file in the user's browser (e.g., vscode.env.openExternal(uri) is an acceptable solution? Happy to put something together if so.

[jneira]

I played around with this and couldn't really get the webview to render local documentation satisfactorily — it seems like you can't really have file:/// links to local resources, you need special vscode-resource: links. But I might be missing something.

And we could not use those vscode-resource's?

I'm curious if a PR that simply changed the functionality to open the local file in the user's browser (e.g., vscode.env.openExternal(uri) is an acceptable solution? Happy to put something together if so.

Ideally we would want to keep the actual functionality, but well it is broken and we always could switch between internal/external browser by configuration if we recover the actual one so 👍

[mjhoy]

And we could not use those vscode-resource's?

Well, I have not really played around with this, but: does that not mean parsing/transforming the HTML of the generated haddock files? And once you follow a link, what then? Or in general any transitive link (say from a referenced css file).