-
Notifications
You must be signed in to change notification settings - Fork 215
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
Conversation
t.notOk(chrome.runtime.lastError instanceof Error); | ||
}); | ||
|
||
t.end(); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done in f6aece9
@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:
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. |
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. |
Good idea. I'll try fixing the CI issue and push that fix. |
ah I see, 🤦 .... that isn't a nice behavior from circleci, it didn't even show anything to let us understand that |
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 |
This reverts commit 620996b.
Sorry for the noise, Chrome integration tests fail locally SessionNotCreatedError: session not created: This version of ChromeDriver only supports Chrome version 87
There was a problem hiding this 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)}); |
There was a problem hiding this comment.
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'); |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
Great change! 🚀 Are there plans to publish a new release? And, if not: Is |
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)
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). |
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