One frame running phase for every workspace start

[mustard-mh]

Bug description

One frame running phase for every workspace start

This is part because of the time diff between contentAvailable and ideReady

This PR #8313 will wait until contentAvailable to get .gitpod.yml file to parse extensions and download extensions via URL first, and then start IDE

So ideReady will always be after contentAvailable, but after contentAvailable, workspace phase turns to Running.

We can verify it here https://gitpod.io/#github.com/mustard-mh/test/tree/hw/large-file which will download some large files

vscode:
  extensions:
    - http://ipv4.download.thinkbroadband.com/1GB.zip
    - http://212.183.159.230/1GB.zip
    - https://speed.hetzner.de/10GB.bin

Image

Steps to reproduce

Start a workspace

Anything else?

No response

[mustard-mh]

Some options:

1. Add another phase like Waiting IDE
2. Change time to trigger Running phase
3. Change the behavior of code-helper to Plan A [ide] use code flag to install extensions #8313 (comment)
   This will still have running phase, but not stuck in here to wait until extensions are downloaded. Will behavior like we used to be

Any suggestions?

cc @akosyakov @jeanp413 @JohannesLandgraf

[akosyakov]

@mustard-mh I believe there should be already Opening Workspace... phase in the start page code. Could you check why don't we display it in such case?

Change the behavior of code-helper to Plan A #8313 (comment)
This will still have running phase, but not stuck in here to wait until extensions are downloaded. Will behavior like we used to be

I don't think it is relevant the supervisor frontend is always wait till both IDE and content are ready to display.

[mustard-mh]

I don't think it is relevant the supervisor frontend is always wait till both IDE and content are ready to display.

@akosyakov We can verify it here https://gitpod.io/#github.com/mustard-mh/test/tree/hw/large-file which will download some large files

If we start code first, then IDE is ready first(user can access workspace now), and then wait contentAvailabel and install extensions

[akosyakov]

We should have proper loading screen when something delays IDE startup (and we used to have it), regardless of optimization to startup of concrete IDE.

To decide whether we need to optimize we should have a look at diff between content and IDE readiness in analytics. If there is no significant delay in collected data then it does not make sense to invest time in optimization now.

[mustard-mh]

@akosyakov Opening Workspace... It was removed by this PR #8125. Revert this works, it'll display this if IDE ready stuck in something

[akosyakov]

@mustard-mh did you investigate why it was changed like that and what will be broken instead by reverting?

[geropl]

What could help is a special case here: https://github.com/gitpod-io/gitpod/pull/8125/files#diff-d897e36a784992a6a4d3b76c09147a96375add6c80bd14dca49657dcff06b3a7R396-R417

So far we only separate between "dontAutostart" and everything else. But "dontAutostart" is always true when runsInFrame!

The problem is that this code serves multiple purposes:

1. Display state on (fresh) start (in-frame and on dashboard!)
2. Display state on restart, and offer button to open IDE (in-frame only)

We need to find a way distinguish the former two cases from the latter.

[mustard-mh]

Have no idea why we need to check runsInFrame, isn't it always running in an iframe?

based on this, I revert it. cc @akosyakov

But seems we need to display Open Workspace with URL that contains not_found, so I changed this PR to add new props notFound

PS. @geropl not_found have bug too, #8986, it's running but users need to click Open Workspace to make it works