Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: Reject with real Error instances like Firefox does #293

Merged
merged 9 commits into from
Mar 18, 2021

Conversation

rpl
Copy link
Member

@rpl rpl commented Mar 11, 2021

Same as #258, re-created to double-check if circle CI would run the CI job as expected.

Fixes #257

Apart from cross-browser compatibility, this also follows this suggestion https://eslint.org/docs/rules/prefer-promise-reject-errors

@rpl
Copy link
Member Author

rpl commented Mar 11, 2021

@Rob--W would you mind to continue your review in this PR?
we couldn't figure out why CircleCIi is refusing to run the CI job on #258, and on the other PR that @fregante did try to open to workaround the issue in #258.

t.notOk(chrome.runtime.lastError instanceof Error);
});

t.end();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this t.end(); call cause the test runner to pause until the callback for chrome.storage.local.set has been called?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I used t.plan in f6aece9 to ensure the number of assertions is the same for both browsers

@@ -10,12 +10,27 @@ test("browser api object in content script", (t) => {
// On Firefox, window is not the global object for content scripts, and so we expect window.browser to not
// be defined.
t.equal(window.browser, undefined, "window.browser is expected to be undefined on Firefox");

try {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These tests don't really belong to this test. Could you put them in their own location?

Copy link
Contributor

@fregante fregante Mar 13, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same file, different test(), right?

Done in f6aece9

await browser.storage.sync.set({a: 'a'.repeat(10000000)});
t.fail('It should throw when attempting to set an object over quota');
} catch (error) {
t.ok(error instanceof Error);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible to check the error message? This condition is true for almost every error, including "not defined" etc.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in f6aece9

@fregante
Copy link
Contributor

@rpl can you pick f6aece9 or give me push access to your fork?

@rpl
Copy link
Member Author

rpl commented Mar 15, 2021

@rpl can you pick f6aece9 or give me push access to your fork?

just saw this and I did cherry pick f6aece9 into this branch (and I did also invite you in my fork, to make this easier if you'll need to push more changes into this branch).

@rpl
Copy link
Member Author

rpl commented Mar 15, 2021

@fregante the test case is currently failing because at the moment the actual Error message in Firefox is not the same as the error in Chrome:

 error types (Firefox)
    ✖  should be equal
    -------------------
        operator: deepEqual
        diff: "'QUOTA_BYTES quota exceeded'" => "'The storage API will not work with a temporary addon ID. Please add an explicit addon ID to your manifest. For more information see https://mzl.la/3lPk1aE.'"
        source: assert@moz-extension://34eb5c09-f75b-46a0-84d4-49dd697a71da/tape.js:9607:54
        bound@moz-extension://34eb5c09-f75b-46a0-84d4-49dd697a71da/tape.js:9459:32
        equal@moz-extension://34eb5c09-f75b-46a0-84d4-49dd697a71da/tape.js:9768:10
        bound@moz-extension://34eb5c09-f75b-46a0-84d4-49dd697a71da/tape.js:9459:32
        @moz-extension://34eb5c09-f75b-46a0-84d4-49dd697a71da/content.js:45:9

We are mainly interested that the error rejected is instanceof Error that not as much as we are interested into the two error messages being exactly the same, I see that Rob asked to assert the error message in the previous review round and so I propose to just use a different expected error message for Chrome and Firefox while asserting the expected error message.

We could also add the addon id in the test fixture extension manifest (by adding the applications.gecko.id property to the manifest), but the error message will still be slightly different form the one raised on Chrome, in Firefox the error message should be this one: "QuotaExceededError: storage.sync API call exceeded its quota limitations."

and so I think that for the purpose of the test we could also just opt to expect the "The storage API will not work with a temporary addon ID..." error message and don't add an explicit addon id in the test extension manifest.

@fregante
Copy link
Contributor

I think I know what's happening with CircleCI 😂

I registered to be able to see the results (it doesn't even let you look without it) but then I removed the CircleCI from my GitHub account.

So probably they aren't building my commits out of spite.

@fregante
Copy link
Contributor

and so I think that for the purpose of the test we could also just opt to expect the "The storage API will not work with a temporary addon ID..." error message and don't add an explicit addon id in the test extension manifest.

Good idea. I'll try fixing the CI issue and push that fix.

@rpl
Copy link
Member Author

rpl commented Mar 15, 2021

I think I know what's happening with CircleCI joy

I registered to be able to see the results (it doesn't even let you look without it) but then I removed the CircleCI from my GitHub account.

So probably they aren't building my commits out of spite.

ah I see, 🤦 .... that isn't a nice behavior from circleci, it didn't even show anything to let us understand that

@rpl
Copy link
Member Author

rpl commented Mar 15, 2021

and so I think that for the purpose of the test we could also just opt to expect the "The storage API will not work with a temporary addon ID..." error message and don't add an explicit addon id in the test extension manifest.

Good idea. I'll try fixing the CI issue and push that fix.

thank you! ping me if CI is still refusing to run CI jobs on your commits and I'll force update this branch as a last resort to force it

@fregante
Copy link
Contributor

Sorry for the noise, Chrome integration tests fail locally

SessionNotCreatedError: session not created: This version of ChromeDriver only supports Chrome version 87
@rpl rpl requested a review from Rob--W March 16, 2021 16:28
Copy link
Member

@Rob--W Rob--W left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

r+wc

test("error types", async (t) => {
if (navigator.userAgent.includes("Firefox/")) {
try {
await browser.storage.sync.set({a: 'a'.repeat(10000000)});
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on the error message, it seems that you can remove the keys themselves. The API call is rejected without even trying to store the data.

if (navigator.userAgent.includes("Firefox/")) {
try {
await browser.storage.sync.set({a: 'a'});
t.fail('It should throw when attempting to set an object over quota');
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit, the assertion message doesn't match the actual error scenario now, we could change it to t.fail('storage.sync should throw when called from an extension with a temporary id') or something like that.

(@fregante I can make the change and update this branch if you don't get to it first, in the end it is just a small nit related to an assertion message and so I don't mind if you prefer that I make the change and then land this on master).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor tweak to one of the assertion messages applied in edaa539.

@rpl rpl merged commit 5ab825b into mozilla:master Mar 18, 2021
@fregante
Copy link
Contributor

images

@philipp-tailor
Copy link

Great change! 🚀

Are there plans to publish a new release?

And, if not: Is mozilla:master stable? If so, I might change my dependency to pull from the branch instead.

@rpl
Copy link
Member Author

rpl commented Apr 9, 2021

Great change! rocket

Are there plans to publish a new release?

Yes, we should be publishing it soon, I have been busy with other projects and I didn't got to come back to this (I'll mainly need to review the changes that we will release, generate a changelog and agree with Rob if we should release it as a new major version, which I think it may be reasonable based on some of the changes that I recall)

And, if not: Is mozilla:master stable? If so, I might change my dependency to pull from the branch instead.

We run integration tests on each change and so it should be fairly stable, but there may be some changes in behavior that may be worth to keep into account (well, one is this one, which you are already aware of).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Errors aren't instances of Error
4 participants