crates.io no longer works when site local storage is blocked

[ijackson]

Current Behavior

Message "serde_json: Failed to load crate data"

Expected Behavior

It works and displays the page

Steps To Reproduce

Use firefox. In Preferences, Privacy, disable all cookies and site local storage.

Visit https://crates.io/crates/serde_json

Environment

• Browser: firefo 128.6.0esr (64-bit)
• OS: Debian trixie (testing) amd64

Anything else?

Looking at the dev tools, I see that crates.io has apparently downloaded over a megabyte of javascript from https://crates.io/assets/vendor.c4beaab2838a0819e1c51f1dd827a65d.js Why does presenting this simple page involve a megabyte of JS? It should involve no JS at all.

[Turbo87]

because that's how the page was built originally and the crates.io had other high-priority things to work on. all alternatives have their own tradeoffs and migrating the whole frontend to something else is not a small task.

[ijackson]

because that's how the page was built originally and the crates.io had other high-priority things to work on

I assume that this is in response to my "why a megabyte of JS" question.

Re the use of local storage:

This is a regression. I was travelling recently, so I'm' not sure precisely when it changed, but it worked correctly a month ago.

[eth3lbert]

because that's how the page was built originally and the crates.io had other high-priority things to work on

I assume that this is in response to my "why a megabyte of JS" question.

Re the use of local storage:

This is a regression. I was travelling recently, so I'm' not sure precisely when it changed, but it worked correctly a month ago.

The failure to load the crate does indeed seem unusual to me. However, this failure occurred at the commit we currently deployed, but it works without any issue on the latest commit. So, this seems like a regression. I haven't bisected the commits to figure out where it was introduced, but fortunately, this will be resolved automatically once we deploy the latest commit later. So, I think we should be fine :D

[ijackson]

fortunately, this will be resolved automatically once we deploy the latest commit later. So, I think we should be fine :D

OK thanks! I'll watch this space.

[eth3lbert]

fortunately, this will be resolved automatically once we deploy the latest commit later. So, I think we should be fine :D

OK thanks! I'll watch this space.

Ah, wait, I was wrong. It seems I failed to test it with all cookies disabled on the latest commit for some reason, and it continues to fail with the latest commit, even on the landing page. It works if we revert ember-data back to version v5.3.11. I think we could lock its version at this point for a quick fix.