You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Homepage showcase: chromeExtensions API returns null for all IDs #2277
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.
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)
Update the CSS selector for weeklyActiveUsers to match Google's current DOM structure
Consider making weeklyActiveUsers optional so a selector miss doesn't null out the entire entry — return partial data with users: 0 instead of null
Add a new test fixture from the current CWS HTML to catch future DOM changes in CI
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
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
Activity
shadoath commentedon Apr 17, 2026
Root cause found
The Chrome Web Store crawler at
wxt-dev/queueuses CSS selectors to scrape extension data fromchromewebstore.google.com. Google has changed their DOM structure, breaking at least theweeklyActiveUsersselector.Specific breakage
The selector for weekly active users:
"...251 users"→ parses correctly"Add to Chrome"→parseIntfails →tryExtractthrowsSince
tryExtractis non-optional forweeklyActiveUsers, the thrown error propagates up fromcrawlExtension, and the GraphQL resolver catches it and returnsnullfor 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
Suggested fixes (in
wxt-dev/queue)weeklyActiveUsersto match Google's current DOM structureweeklyActiveUsersoptional so a selector miss doesn't null out the entire entry — return partial data withusers: 0instead ofnullaiktb commentedon Apr 17, 2026
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 commentedon Apr 17, 2026
Fix submitted
PR with the fix: wxt-dev/queue#9
wbwSoftware commentedon Apr 17, 2026
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 commentedon Apr 17, 2026
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.
It's not rendered server-side, so there's no SEO benefits that I'm aware of, nor intended to be.
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 commentedon Apr 18, 2026
Thanks for the PR, released and fixed in https://github.com/wxt-dev/queue/releases/tag/v0.4.10
shadoath commentedon Apr 18, 2026
Agreed, I think this is awseome way to show off. Glad you have it.
Good point, should have realized the server side load.
Best way to be, along with good discernment.
Thanks again for this project!