CE-132 Loading a project with many assets can fail

[cwillisf]

Expected Behavior

Any given project should either load correctly or should display a Scratch error messages. Repeated attempts to load the same project should be consistent.

Actual Behavior

If a project has many assets (>2000) it can cause bad behavior. For example:

• the project might fail to load with a Scratch bluescreen on the first attempt, but succeed on a later attempt (once some of the assets are cached)
  • This has been observed on the website when some assets fail to load with net::ERR_INSUFFICIENT_RESOURCES in the network tab.
• the project might crash Chrome / Chromium's rendering process
  • This has been observed in the desktop app. From a user perspective, the whole editor is replaced by a blank white window.

See also FreshDesk ticket 323025, especially the "Technical Issue Link" attached to that ticket.

Steps to Reproduce

1. Find or create a project with >2000 assets
   • The example I have on hand has 2114 assets. It's possible the threshold is much lower; I haven't tested.
2. Save the project on the website, or to an SB3 file
3. Try to load the project

Operating System and Browser

White screen: Scratch desktop app on Windows
Other errors: Chrome / Chromium, any OS

[cwillisf]

Some info and discussion about net::ERR_INSUFFICIENT_RESOURCES is available here: https://bugs.chromium.org/p/chromium/issues/detail?id=108055

Batching / throttling asset requests might help, but "explicitly detecting net::ERR_INSUFFICIENT_RESOURCES will be difficult" because "this is considered a security-related side-channel, and this kind of error should be kept opaque from javascript" according to the discussion here:
GoogleChrome/workbox#2528

[apple502j]

Duplicate of #5844

[BryceLTaylor]

@apple502j it is not a duplicate of that issue. It probably does have the same root cause, but this one has a different result and will need to be addressed separately.

[apple502j]

@BryceLTaylor The "Actual Behavior" section seems to point out the same thing; a BSOD on Chrome that gets fixed with a reload.

[BryceLTaylor]

The main problem here is the whole window goes white and there is no reload button. So the solution will have to address the failure state in a way that does not rely on the browser's functionality.

[benjiwheeler]

Moving detail from #8403 to here:

Expected Behavior

1. load a project with a high number of images, such as https://scratch.mit.edu/projects/697304342/
2. click the green flag
3. see the costumes normally
4. project runs at normal speed

Actual Behavior

3. some costumes appear as question marks
4. project runs incredibly slowly

System Details

Unclear if this is system/browser dependent; I'm using an M1 mac running chrome 103

Discussion

One of our devs said "I'm not sure why it happens. It seems to be related to loading MANY assets. Often, if you reload the project it'll load more of the assets successfully (I assume the browser cache is helping) and after an iteration or two it might get to 100%."

I tried loading https://scratch.mit.edu/projects/697304342/, and it loaded with many question marks and ran incredibly slowly -- like 1/20th its intended speed. I then tried reloading it twice more, and on the third load, everything seemed to finally load completely, and the project ran fast.

Notably, the project works fine on the first load with Turbowarp: https://turbowarp.org/697304342 -- perhaps we should ask them what they're doing differently?

One possibility: we might be hitting a limit for parallel web requests. We don't currently do anything to throttle asset requests -- the editor throws every asset request to scratch-storage, and scratch-storage makes a fetch request immediately. We rely on the browser to schedule (throttle) these requests.

In scratch-desktop, where those are actually file loads instead of web requests, that ends up destroying performance in some cases, like the asset library display. We had to add throttling in that case, but that throttling implementation is specific to the asset libraries.

Maybe moving that throttling into scratch-storage would help with performance and possibly fix this ERR_INSUFFICIENT_RESOURCES thing. It would also be a step toward merging the different branches of scratch-gui, which is another long-term goal of ours.

[benjiwheeler]

Moving detail from #5844 to here:

Expected Behavior

All projects load normally.

Actual Behavior

A few projects have come to our attention that don't load in chrome, instead giving a blue error screen (BSOD). These projects have tons of assets (hundreds).

https://scratch.mit.edu/projects/371197630/
https://scratch.mit.edu/projects/399970272/
https://scratch.mit.edu/projects/339207237/

If you look in the network tab as the project loads you will see that many assets load. After loading a number of them, they start coming back as failed requests. This seems to only happen when using Chrome.

The assets that fail to load can be loaded directly from the api.

Reloading the page seems to work. The project is viewable.

The current theory is that this is a chrome bug which can only load a certain number of assets per page. It seems that the first time you load it, the browser caches the responses for the images it finds, then only has to load the images it failed to load the first time, so it works the second time.

Steps to Reproduce

Load one of the two projects listed above in chrome.
Note: you get a BSOD
reload the page
Note: the project loads this time. It may take multiple reloads.

Load the project in another browser
Note: the project loads.

Operating System and Browser

Microsoft Edge (Win10)
Chrome (Win10)
Chrome (MacBook Pro)
Android smartphone using Firefox, Chrome or Opera.
iPhone using Safari or Chrome
Linux Chrome

It might be better on Safari (MBP) and, by some reports, Chrome (Android)

[RokCoder]

Recent changes seem to have made it so loading a project with lots of costumes via "look inside" takes substantially longer and results in a large amount of '?' (unloaded) costumes. Loading it via standard project view seemed much faster than normal and resulted in no missing costumes. I tested this numerous times with https://scratch.mit.edu/projects/152742032 and https://scratch.mit.edu/projects/152742032/editor using Chrome browser in Windows 10.