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

[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

[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!

[SteveSandersonMS]

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.