Skip to content
This repository has been archived by the owner on Aug 3, 2023. It is now read-only.

If wrangler preview starts the first browser process, it hangs waiting for it to exit #516

Closed
kentonv opened this issue Sep 4, 2019 · 4 comments 路 Fixed by #1495
Closed
Assignees
Labels
bug Something isn't working investigate
Milestone

Comments

@kentonv
Copy link
Member

kentonv commented Sep 4, 2019

馃悰 Bug Report

Environment

  • operating system: Linux
  • browser: Google Chrome
  • output of rustc -V: N/A
  • output of node -v: N/A
  • output of wrangler -V: 1.2.0

Steps to reproduce

  • Completely close your browser.
  • Run wrangler preview --watch.

What did you expect to see?

Wrangler starts the browser, then proceeds to watch for changes to the source code.

What did you see instead?

Wrangler starts the browser, then hangs waiting for the browser to exit before it begins watching for changes, defeating the purpose of --watch.

The problem is that running the browser (e.g. running google-chrome <url> on the command line) behaves differently if another browser process is already open or not.

  • If a process is already running, the new process tells the existing process to open a new tab, and then the new process exits immediately.
  • If no browser process is already running, the new process becomes the main process, and does not exit until the user closes all browser windows.

When Wrangler opens a preview window by executing the browser, it waits for the process to exit before proceeding. That works fine in the first case but not the second case.

Instead, Wrangler should start the browser process and then not wait for it. Ideally, it would also start the browser in a new process group (using setpgid()), so that ctrl+C'ing wrangler doesn't kill the browser process, and a new session ID (using setsid()), so that closing the terminal doesn't kill the browser process. It should probably also redirect the browser's stdin/stdout/stderr to /dev/null.

@EverlastingBugstopper EverlastingBugstopper added bug Something isn't working investigate labels Nov 11, 2019
@ashleymichal
Copy link
Contributor

@kentonv is this still a problem in v1.9.0? it appears that if it is, it is not reproducible on mac (or at least mine).

@kentonv
Copy link
Member Author

kentonv commented May 18, 2020

Yeah, I can still reproduce this.

It's possible that Chrome on Mac behaves differently when run from the command line -- maybe it doesn't block the command line like it does on Linux. Certainly on Windows I'd expect Chrome does not block the command line... but naively I'd expect Mac to behave closer to Linux than to Windows. But anything is possible.

It's also possible that you already have a chrome process running in the background. Even if you close all chrome windows, sometimes it'll leave a process running for the purpose of implementing apps or notifications or some other nutty feature. To see the behavior I'm seeing, you really have to have completely killed Chrome from the background such that wrangler is causing it to start fresh.

@stale
Copy link

stale bot commented Jul 17, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix label Jul 17, 2020
@stale
Copy link

stale bot commented Jul 25, 2020

This issue has been automatically closed because it has not had recent activity. You may re-open the issue if it is still relevant.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working investigate
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants