Skip to content

localhost refused to connect when viewing pdf file #1862

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

Closed
fockez opened this issue Jul 3, 2020 · 7 comments
Closed

localhost refused to connect when viewing pdf file #1862

fockez opened this issue Jul 3, 2020 · 7 comments
Labels
bug Something isn't working extension The issue needs to be fixed in the extension
Milestone

Comments

@fockez
Copy link

fockez commented Jul 3, 2020

I use the code-server with latex-workshop for remote latex editing. But there is a problem that when I try to view the pdf file, it always reported "localhost refused to connect". I made it in docker using Ubuntu 20.04 image and work with jupyterhub, and also tried directly in Ubuntu 20.04, both the same error.

Thanks.

  • Web Browser: Chrome/New Edge
  • Local OS: Windows 10
  • Remote OS: Ubuntu/Ubuntu Docker
  • Remote Architecture: X64
  • code-server --version: 3.4.1
@fockez fockez changed the title localhost refused to connect when review pdf file localhost refused to connect when viewing pdf file Jul 3, 2020
@fockez
Copy link
Author

fockez commented Aug 10, 2020

From the discussion from Latex-Workshop, the pdf viewer listen only internal address localhost, I see that there is /proxy// sub path for this, but when I use this, still get error connect ECONNREFUSED. Is that possible to solve this?

@code-asher
Copy link
Member

/proxy/<port number>/ doesn't show the PDF viewer for you? I tried testing but the extension from our marketplace looks like it wasn't built properly so it errors on activation and I haven't been able to test myself yet.

We have an issue for this localhost problem (#1510) but it requires changes on the extension's end. I'm not sure whether there's a way for us to fix it on our end or for users to work around it manually. We might be able to automatically replace localhost with the proxy URL but I ran into issues the last time I tried that.

@nhooyr
Copy link
Contributor

nhooyr commented Aug 17, 2020

cc @cmoog re the extension not activating.

@fockez
Copy link
Author

fockez commented Aug 20, 2020

From my test, the extension works. Only pdf viewer fails. And the standalone pdf viewer extension vscode-pdf works. But they cannot work together, and latex-workshop develop group insist the localhost way for the security consideration.

@nhooyr nhooyr added bug Something isn't working extension The issue needs to be fixed in the extension labels Aug 31, 2020
@krao88
Copy link

krao88 commented Sep 12, 2020

I have the same exact use case and problem.
More specifically, choosing the tab setting for https://github.com/James-Yu/LaTeX-Workshop/wiki/View#latex-workshopviewpdfviewer results in the error message "Error loading webview: Service Workers are not enabled in browser. Webviews will not work", while choosing the browser setting results in a new browser tab being opened pointinting at localhost (as an aside, to replicate one might need to install latex workshop directly from the vsix file, installing from within code-server did not work for me, see #1828).

The reference issue at the latex-workshop repo is: James-Yu/LaTeX-Workshop#1265, where it is claimed that

To my opinion, code-server itself should support WebView as VS Code Remote Development does. This is an upstream issue.

Is there a way to resolve this impasse?

@code-asher
Copy link
Member

That error might mean that you aren't using https since browsers only allow service workers in a secure context.

The only way I can think of to work around the localhost issue without making the required code changes is to forward localhost ports to the remote host. Otherwise the only solution is to wait until we can implement one of the fixes.

@stale
Copy link

stale bot commented Oct 26, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no activity occurs in the next 5 days.

@stale stale bot added the stale label Oct 26, 2021
@stale stale bot closed this as completed Nov 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working extension The issue needs to be fixed in the extension
Projects
None yet
Development

No branches or pull requests

5 participants