Priya — you asked me last week whether the price-drop watcher you're building should just poll the product page every minute "to be safe." Before you build that in, let me walk you through the whole thing, because the polling interval is actually the smallest decision here, and getting the shape right up front will save you a review cycle or two before your launch.
Start with the prompt itself. You told me "an extension that watches this page and tells me when the price drops," and that's a fine idea but it's not yet a spec — the builder needs to know when it acts, not just what it does. Your watcher is the third of three trigger shapes, and it's worth knowing the other two even though you don't need them, because the shape determines the permissions and the permissions determine your review timeline.
- Click-to-act is the cheapest: a popup that runs once against the current page when someone hits the toolbar icon — think "pull every price on this page into a list."
- Always-on content script runs automatically on a URL pattern you specify — good for something like highlighting a competitor's name on every page under a domain, but you have to say the pattern explicitly, because "on our internal sites" gets guessed narrower than you meant.
- Your case is the third: a background watcher, state that persists whether or not the tab is open, running on a service worker under MV3, badging the icon when something changes.
That's the one shape where the builder should push back on you with a follow-up question, and it will — because the polling number is a real trade-off, not a formality.
Which brings me back to your "every minute" instinct. I asked for almost exactly your build a while back — watch a page, badge the icon on a price change — and the first pass polled every 60 seconds. Worked fine for one person testing locally. Multiply that by however many people actually install this thing and you're hammering someone's product page for no reason, because prices on a normal retail listing don't move more than a few times a day. Tell the builder "check every 30 minutes" in the prompt. It's not a compromise, it's the more honest ask — nobody needs sub-minute alerts from a browser extension, and you'll thank yourself later when you're not explaining to a reviewer why your extension phones home 1,440 times a day.
The parts you don't have to think about
You mentioned being nervous about the manifest — don't be, that's the one thing you genuinely don't need to touch. Both stores require Manifest V3 now; MV2 stopped being accepted for new listings and Chrome's been actively sunsetting the MV2 extensions still live. The headline change under MV3 is that your background logic runs as a service worker instead of a persistent background page — it spins up on an event, the browser can kill it between events, and state has to go through chrome.storage instead of just living in a variable. That's exactly the kind of lifecycle detail the builder writes correctly by default. You'll never see a manifest file unless you go looking for one.
What you should actually spend your attention on is permissions, because that's the thing that decides how fast your review goes, not the code. Your watcher needs alarms for the polling and probably storage for remembering the last price — it does not need tabs or <all_urls>, and if you ask for "the ability to work on any site eventually" because you might expand it later, the builder will build to that and you'll be requesting broad host access for a feature that doesn't exist yet. That's the scariest line item in the install dialog — "read and change data on every site you visit" — and it's also the thing that bumps an automated review into a manual one. Describe what it does today. Widen it later if you actually need to.
Two more things worth thirty seconds of attention before you call this done: the popup UI and the icons.
- Popup UI — a default options page, bare checkboxes, no hierarchy, is a real source of one-star reviews that have nothing to do with whether the extension works. Yours only has a couple of settings (the URL, maybe the interval), but it should still look like it belongs to a product, not a form dump.
- Icons — get the icon checked at all four Chrome sizes (16, 32, 48, 128px, with a slightly different matrix for Firefox), because a logo that's crisp at 128 turns into a smudge at 16, which is exactly where it lives in a crowded toolbar most of the day.
Before you touch either store
Test this for real, not just in the chat preview. What you get out of the build is an actual loadable extension, so go to chrome://extensions, flip on developer mode, "load unpacked," and run it against the actual product page you care about — not a simulated version of it. I'd specifically check two things by hand: does the install permission prompt say what you'd expect given what you asked for, and what happens if the content script ever hits a page it wasn't built for — does it fail quietly or throw something visible? Both take under a minute and both are the kind of bug that's obvious the moment you look and invisible if you don't.
When you're ready to actually ship, you'll go through your own developer accounts on both stores — you own the listing, this platform doesn't manage it for you. And I want to flag that the two stores are not remotely symmetric, because I don't want you to plan your launch date assuming they are.
| Store | Submission process |
|---|---|
| Chrome | Autofills the listing — title, description, category, and the permission justification text the review actually reads, generated from what the code does rather than typed up separately, which matters because mismatched justifications are a common rejection reason on their own. |
| Firefox | Essentially hands-off; Mozilla's pipeline is lighter and the submission just goes through. |
The listing kit that generates after your build finishes will also produce screenshots taken from your extension actually running (not a mockup), listing copy, and privacy-practice answers checked against the real code instead of filled in from memory. That last part is more important than it sounds for something that talks to an external page: Chrome's privacy questionnaire asks flat yes/no questions about data handling, and answering "no" to "does this collect data" when your watcher is polling and storing prices is the kind of small dishonesty that gets pulled after launch, not just rejected before it. Having the answers checked against what the code does closes that gap for you automatically.
| Store | Typical review time |
|---|---|
| Firefox | Hours, sometimes under one |
| Chrome | A couple of days, occasionally closer to two on a bad week |
Background-persistence extensions like yours are more likely to land in the slower, manual-review lane than a simple click-to-act one. Neither of us can pull a lever on that queue. Plan your announcement around Chrome's timeline, not Firefox's, and don't schedule anything for the same day you submit.
One last thing, since I know you — you're already thinking about adding "sync my watch list across devices" and "track price history over time" once this ships. That's fine, but know that each of those is a new permission, and a new permission can mean a slower review than the one you just went through. If you're confident you want the bigger version, it's genuinely better to prompt for it now and eat one slower review than to trickle permissions in one at a time. If you're not sure yet, ship what you have — a tightly-scoped watcher clears fast, gets you real usage, and real usage is worth more right now than a longer feature list sitting in Chrome's queue. You can always ask for more later; you can't get this launch back once it's stuck in manual review over something you didn't need yet.
