Homepage showcase: chromeExtensions API returns null for all IDs

[shadoath]

Description

The chromeExtensions query on queue.wxt.dev/api returns null for every Chrome extension ID. This means the homepage showcase ("Using WXT" section) shows only Firefox data — no Chrome links, user counts, or ratings.

The firefoxAddons query works correctly.

Steps to reproduce

# Chrome — returns null for every ID tested
curl -s 'https://queue.wxt.dev/api' \
  -H 'Content-Type: application/json' \
  -d '{"query":"{ chromeExtensions(ids: [\"hmdcmlfkchdmnmnmheododdhjedfccka\", \"elfaihghhjjoknimpccccmkioofjjfkf\", \"pdnenlnelpdomajfejgapbdpmjkfpjkp\"]) { id name users } }"}'
# → { "data": { "chromeExtensions": [null, null, null] } }

# Firefox — works fine
curl -s 'https://queue.wxt.dev/api' \
  -H 'Content-Type: application/json' \
  -d '{"query":"{ firefoxAddons(ids: [\"github-better-line-counts\"]) { slug name users } }"}'
# → returns valid data

Impact

• Extensions that only have a chromeId (no firefoxSlug) are completely missing from the showcase
• Extensions with both stores only show Firefox stats and a Firefox link — Chrome link is absent
• User counts are understated (missing Chrome users)

Expected behavior

chromeExtensions should return extension metadata (name, icon, users, rating, storeUrl) the same way firefoxAddons does.

[shadoath]

Root cause found

The Chrome Web Store crawler at wxt-dev/queue uses CSS selectors to scrape extension data from chromewebstore.google.com. Google has changed their DOM structure, breaking at least the weeklyActiveUsers selector.

Specific breakage

The selector for weekly active users:

main > * > section:first-child > section > div > div:last-child

• Old HTML (Feb 2025 test fixture): returns "...251 users" → parses correctly
• Live HTML (Apr 2026): returns "Add to Chrome" → parseInt fails → tryExtract throws

Since tryExtract is non-optional for weeklyActiveUsers, the thrown error propagates up from crawlExtension, and the GraphQL resolver catches it and returns null for the entire extension entry.

Secondary issue

Even if other fields parse fine, one broken selector nullifies the whole extension. The crawler has no partial-result fallback — it's all or nothing.

Reproduction

// Tested with linkedom against live CWS HTML for "Eye Dropper" (hmdcmlfkchdmnmnmheododdhjedfccka)
// weeklyActiveUsers selector → "Add to Chrome" (wrong element)
// rating selector → "4.3" (still works)
// og:* meta tags → all still work

Suggested fixes (in wxt-dev/queue)

1. Update the CSS selector for weeklyActiveUsers to match Google's current DOM structure
2. Consider making weeklyActiveUsers optional so a selector miss doesn't null out the entire entry — return partial data with users: 0 instead of null
3. Add a new test fixture from the current CWS HTML to catch future DOM changes in CI

[aiktb]

On a side note, does WXT really need to maintain such a homepage list?

This list is constantly growing. Most of the Chrome extensions on it seem to have very low usage, and there's no guarantee that it's free of malware.

Perhaps removing this list would be a better decision. At least from my perspective, this list doesn't seem to make much sense.

[shadoath]

Fix submitted

PR with the fix: wxt-dev/queue#9

[wbwSoftware]

It is a marketing callout for people to use WXT. a Homepage link to the extension is a big grab for SEO.

Your callout for malware and size is worthy though, maybe limit to top 20/30 with load more option.

[aklinker1]

This list is constantly growing. Most of the Chrome extensions on it seem to have very low usage...

At first, it was meant to show WXT is production ready, in use by some popular extensions. So you should use it too. That's still true to some extent, but I also want people who have made something with WXT to have a place to show it off, even if they only have a few users.

a Homepage link to the extension is a big grab for SEO.

It's not rendered server-side, so there's no SEO benefits that I'm aware of, nor intended to be.

... and there's no guarantee that it's free of malware.

This is true. I could see someone targeting other dev's by posting an extension here. Though I would trust the store review processes to catch this over myself.

So I guess it's a balance between giving people a place to showcase their work vs taking proactive steps to protect against malicious extensions, and I'm currently leaning towards trusting people lol

[aklinker1]

Thanks for the PR, released and fixed in https://github.com/wxt-dev/queue/releases/tag/v0.4.10

[shadoath]

This list is constantly growing. Most of the Chrome extensions on it seem to have very low usage...

At first, it was meant to show WXT is production ready, in use by some popular extensions. So you should use it too. That's still true to some extent, but I also want people who have made something with WXT to have a place to show it off, even if they only have a few users.

Agreed, I think this is awseome way to show off. Glad you have it.

a Homepage link to the extension is a big grab for SEO.

It's not rendered server-side, so there's no SEO benefits that I'm aware of, nor intended to be.

Good point, should have realized the server side load.

... and there's no guarantee that it's free of malware.

This is true. I could see someone targeting other dev's by posting an extension here. Though I would trust the store review processes to catch this over myself.

So I guess it's a balance between giving people a place to showcase their work vs taking proactive steps to protect against malicious extensions, and I'm currently leaning towards trusting people lol

Best way to be, along with good discernment.

Thanks again for this project!