Skip to content

Homepage showcase: chromeExtensions API returns null for all IDs #2277

Closed

Description

@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.

Activity

  1. shadoath commented on Apr 17, 2026

    @shadoath
    ContributorAuthor

    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
  2. aiktb commented on Apr 17, 2026

    @aiktb
    Contributor

    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.

  3. shadoath commented on Apr 17, 2026

    @shadoath
    ContributorAuthor

    Fix submitted

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

  4. wbwSoftware commented on Apr 17, 2026

    @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.

  5. aklinker1 commented on Apr 17, 2026

    @aklinker1
    Member

    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

  6. aklinker1 commented on Apr 18, 2026

    @aklinker1
    Member

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

  7. shadoath commented on Apr 18, 2026

    @shadoath
    ContributorAuthor

    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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions