Fix Float Rank hyperlinks for Souvenirs/StatTraks

[rxl211]

I noticed that on Steam inventories, when you selected a StatTrak or Souvenir item and it had a displayed float Rank, clicking on the link would always take you to the database with a category=1 (Normal) filter selected, even though the selected item was StatTrak/souvenir.

Example:

The root cause seemed to be that the itemInfo.full_item_name field was never populated, and so downstream code which looks at full_item_name to derive the correct category filter when constructing the hyperlink would always just default to category=1.

This PR includes a change to selected_item_info.ts to populate full_item_name inside of processSelectChange().

I verified this fixes the bug locally by loading the unpackaged extension in Chrome. I did not test on Firefox.

---

Note

Low Risk
Small change to outbound Float DB URL construction for rank links; no auth, data, or payment impact.

Overview
Fixes Float Rank links on Steam inventory items so StatTrak and Souvenir skins open csfloat.com/db with the correct category filter instead of always using Normal (category=1).

Inspect handling now sets is_souvenir and is_stattrak on ItemInfo from decoded inspect data (souvenir quality 12, StatTrak via killeaterscoretype). getFloatDbLink uses those flags for category selection (StatTrak → 2, Souvenir → 3, normal → 1) rather than substring checks on full_item_name, which was often unset. If either flag is missing, the link uses category=0 (unfiltered) instead of incorrectly defaulting to Normal.

^{Reviewed by Cursor Bugbot for commit 86d9c5c. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want higher recall? High effort reviews run extra passes and find more bugs. A team admin can switch effort levels in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 6f5342d. Configure here.}

[GODrums]

Thanks for the contribution and finding this bug! Added a small comment to make our parsing a bit more reliable and resolve the issue in SCM as well

[GODrums]

Combining data points from different sources will make this process harder to reproduce in other places (e.g. the same issue occurs in our SCM enhancements).

I would prefer reusing our existing solution from fetch_inspect_info.ts

extension/src/lib/bridge/handlers/fetch_inspect_info.ts

Lines 134 to 135 in d46eac3

	const stattrak = decoded.killeaterscoretype !== undefined;
	const souvenir = decoded.quality === 12;

and just modify the string parsing in getFloatDbCategory to use the available info.

We could remove full_item_name from ItemInfo to make this a bit more clear.

[rxl211]

@GODrums thanks, I wasn't thinking about SCM! I did initially look at getFloatDbCategory but the problem I ran into is that ItemInfo doesn't contain anything to infer StatTrak from. I see now that you can infer souvenir by quality == 12 though, so that can be done easily.

Are you suggesting adding an is_stattrak property to ItemInfo in fetch_inspect_info.ts? I'm still unsure of what a common area would be to fill in the property. I tried doing so in fetch_inspect_info.ts but my new fields never showed up when I tried outputting the ItemInfo object to console.

I'm also not sure what kind of caching exists in the extension. But that's not the reason I don't think it was working for me because I tried going to SCM pages I had never been to before.

[GODrums]

As shown in the code sample above, you can determine if an item is StatTrak by checking if killeaterscoretype is defined on the decoded inspect link.

Given that these checks are simple, there should be no need to persist them in itemInfo, you may just replace the string parsing with those checks in getFloatDbCategory

[rxl211]

I got it working with the decoded inspect link, but since getFloatDbCategory didn't seem to already have an inspect link handy I had to plumb it through.

[GODrums]

My bad, missed that. In that case, feel free to annotate those states (stattrak, souvenir) in ItemInfo.
Performance-wise we should avoid running multiple decodings if not absolutely necessary, especially not in injected scripts.

[rxl211]

@GODrums ok thanks. I have a version working where the fields are set in processInspectItem() but I initially wasn't seeing my new fields show up in the ItemInfo that getFloatDbCategory had. At first I fixed it by deleting threshold_cache in Chrome devtools but later wasn't able to repro.

In short, are there any cache considerations to keep in mind when existing users upgrade / are there cases where ItemInfo does not update (and thus skips the new fields) for items users have recently looked at or something like that?

Either way, I reverted the last change and pushed the latest version so you can take a look. I'm going out of town for 7 days so won't be able to get to any edits until next week.

[GODrums]

Thanks, looking much more simple now!

Most likely this happened because the extension's HMR in dev-mode only reloads changed files (but not cache-related files for example). This is generally not a concern for production extension updates as those reload the whole extension.

[GODrums]

Is this check necessary? Applying the "normal" category should work for non-skins as well afaik

[GODrums]

Thanks, looking much more simple now!

Most likely this happened because the extension's HMR in dev-mode only reloads changed files (but not cache-related files for example). This is generally not a concern for production extension updates as those reload the whole extension.

[GODrums]

Please also ensure to run the linter so our tests pass (npm run lint)!