Give the store icon the padding the store asks for - #73
Merged
Merged
Conversation
souta registered the developer account and asked whether CI could take it from there. Mostly yes, and the line is not where you would guess. The Chrome Web Store API cannot create a listing. Description, screenshots, category and the data disclosure are not reachable from it, and the extension ID does not exist until the Store listing and Privacy tabs have been filled in by a person. So the first submission is by hand and always will be. Every update after it is a package upload and a publish, and both are API calls. `store.yml` does those on a published release. The human gate is not removed, it moves: merging the release PR is the decision, and what reaches the store is the package that was built, tested and attached to that release rather than one dragged into a browser. A service account rather than a refresh token. A refresh token issued while the OAuth consent screen is still in "Testing" expires after a week, so the pipeline would work today and fail next month having changed nothing. v2 of the API takes service accounts, which do not expire; the JSON key is one secret and the dashboard takes the account's email under Account. It refuses before authenticating when a secret is missing, and names which. An authentication error twenty lines into a log is the same fact told worse. Two things the docs say and experience will otherwise teach: the API does not set visibility, so an item whose visibility was changed by hand must be published by hand once before the API will do it again; and a version cannot be uploaded twice, which is what the `versions agree` check has been protecting all along. The endpoints and the service-account flow are from the Chrome for Developers documentation rather than memory, and the action SHA resolves to the v3.0.0 tag rather than the moving `v3`. Signed-off-by: Souta <shimozono-sota631@g.ecc.u-tokyo.ac.jp>
The form asks whether the extension uses remote code and the answer is no, but it is not an obvious no and the reason was nowhere. `applyPac` fetches `http://127.0.0.1:<port>/proxy.pac` from the user's own daemon and hands the text to `chrome.proxy` as `pacScript.data`. Chrome defines remotely hosted code as "anything that is executed by the browser that is loaded from someplace other than the extension's own files", and a PAC is JavaScript. So the case that could contradict the answer exists, and a reviewer reading seven kilobytes of `background.js` will see it. It is still no: the PAC runs in the browser's network stack rather than in the extension, `chrome.proxy` is a first-party API whose documented input is exactly this, and it arrives from loopback rather than from a server the author controls -- which is the thing the policy exists to prevent. The fallback is scoped here too, because the moment to work it out is not the moment a rejection arrives. The PAC is a function of the suffix and the port and the extension knows both, so generating it locally settles the question without losing what the fetch was for: the suffix stays data the daemon reports, so changing it still needs no extension release. Signed-off-by: Souta <shimozono-sota631@g.ecc.u-tokyo.ac.jp>
Measured rather than eyeballed: the 128 held 120x120 of artwork with 4 pixels of padding, where the listing wants 96x96 with 16 on every side. The store draws its own rounded frame around whatever it is given, so a tile that fills the canvas has that frame drawn across its corners. Only the 128, because the rule is the store's. The toolbar icons want the opposite -- padding at sixteen pixels across is wasted pixels -- so 16, 32 and 48 still fill their square. Still one drawing. `fill` divides the sampled coordinate, so a smaller value takes the same shape from further out and lands it smaller in the same canvas; it is not a second set of numbers to keep in step with the first. icon-16 canvas 16x16 artwork 16x16 padding 0 icon-32 canvas 32x32 artwork 30x30 padding 1 icon-48 canvas 48x48 artwork 46x46 padding 1 icon-128 canvas 128x128 artwork 96x96 padding 16 Re-running still produces byte-identical files, which is what keeps a regenerated icon out of every diff that touches the extension. Signed-off-by: Souta <shimozono-sota631@g.ecc.u-tokyo.ac.jp>
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
souta hit an icon problem filling in the listing. The package is not missing one — the zip carries all four and the manifest points at them correctly — but measuring the 128 against the store's stated geometry found it wrong:
The store draws its own rounded frame around whatever it is given, so a tile that fills the canvas has that frame drawn across its corners.
Only the 128 changes. The rule is the store's, and toolbar icons want the opposite — padding at sixteen pixels across is wasted pixels — so 16, 32 and 48 still fill their square:
Still one drawing:
filldivides the sampled coordinate, so a smaller value takes the same shape from further out. It is not a second set of numbers to keep in step with the first. Re-running still produces byte-identical files, checked by regenerating and diffing hashes.