Skip to content
This repository was archived by the owner on Apr 8, 2020. It is now read-only.
This repository was archived by the owner on Apr 8, 2020. It is now read-only.

Angular-CLI call is starting browser too soon and causing timeout #1447

Closed

Description

@SpeedHighway

I noticed that this appears to have been added in PR #1367

This line:

openBrowserLine = await npmScriptRunner.StdOut.WaitForMatch(
  new Regex("open your browser on (http\\S+)", RegexOptions.None, RegexMatchTimeout),
 StartupTimeout);

Is causing my site to fail every time, unless I manually stop the browser quickly, after pressing F5 (or Ctrl F5) in Visual Studio

Because of the fact that the console window appears and states:

** NG Live Development Server is listening on localhost:5155, open your browser on http://localhost:5155/ **

The browser opens immediately, as it starts to do the build. However, the build definitely does not finish in 50 seconds, so then it times out (displaying an error while building) and gets stuck unusable due to hitting the exception for the timeout. Unfortunately the machine I'm on is not terribly fast so it occurs every time. (And worse if I have Chrome open to the site, because then I can't get it to not timeout, ever.)

The browser should not be opening up until the webpack: Compiled successfully. appears, unless I'm mistaken.

Thanks

Activity

  1. NorDroN commented on Dec 25, 2017

    @NorDroN

    Hi!
    I see that you use some delays, but I can't override properties which set them. It'll be great if I can manage timeouts!

  2. added 2 commits that reference this issue on Jan 2, 2018
    e024e5b
    26d666d
  3. SteveSandersonMS commented on Jan 2, 2018

    @SteveSandersonMS
    Member

    There was a bug here, but it's not quite the same as what the report suggests.

    What the bug is not:

    The issue is not that we log open your browser on... to the console. That's something that Angular CLI (or a similar equivalent for the React dev server) does - we're just watching for when that happens so we know when we can start proxying requests through to Angular CLI.

    Also, this line getting logged is not what causes the browser to open - instead, the browser is opened by .NET tooling because it sees the launchBrowser flag in your launchSettings.json. We don't get to control when that happens. It just happens as soon as the tooling thinks your ASP.NET app is running. We have no way to delay launching the browser until (for example) Angular CLI is ready.

    We can't stop your Angular CLI instance from taking ages to start up, nor can we stop the browser opening long before that has happened.

    What the bug really is:

    In the 2.0.0-preview1 build, the SpaServices.Extensions code contained timeouts so that it could provide useful debugging information in the case where your SPA is badly configured and takes potentially forever to start up. That's good, but the bad thing is that if one of these timeouts fired, then not only the current request would fail, but also all future requests.

    The fix is therefore to ensure that the timeouts are only applied on a per-request basis, so that even if your first request does time out while waiting for a very slow SPA dev server to start up, it will still allow subsequent requests to succeed after the SPA dev server has started up. This is now implemented.

    I see that you use some delays, but I can't override properties which set them. It'll be great if I can manage timeouts!

    Good point. This is now implemented too. In the next release, you'll be able to control the timeouts like this:

    app.UseSpa(spa =>
    {
        spa.Options.StartupTimeout = TimeSpan.FromSeconds(123);
    
        // ... other config code here
    });

    The default SPA startup timeout is still 50 seconds.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions