-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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] browser only redirect during load #2462
[fix] browser only redirect during load #2462
Conversation
🦋 Changeset detectedLatest commit: 8c299ca The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
This comment has been minimized.
This comment has been minimized.
|
||
/** @type {import('test').TestMaker} */ | ||
export default function (test, is_dev) { | ||
test('redirect-on-load', '/redirect-on-load', async ({ base, page, clicknav }) => { |
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 don't think this is testing the new functionality you added. I think it's testing server-side redirect. If you look at some of the other tests there should be examples of testing both
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.
Oops. sorry!
I updated!
(This time, again I checked tests that fails without this PR but passes with it.)
And during the update, I faced puppeteer issue due to redirect.
So I edited packages/kit/test/test.js
in the last commit.
export default function (test, is_dev) { | ||
test('redirect-on-load', '/redirect-on-load', async ({ base, page, js }) => { | ||
if (js) { | ||
await page.waitForTimeout(50); |
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 would not use this. Per the docs for that method:
Note that page.waitForTimeout() should only be used for debugging. Tests using the timer in production are going to be flaky. Use signals such as network events, selectors becoming visible and others instead.
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.
Yes. Totally agree with you.
But already few exists tests use waitForTimeout
so I followed that.
Then at least I will update this PR.
But should I refactor exists waitForTimeout
?
I think we should do it to avoid random test failures.
If yes, I will create one more PR which is for existing tests with waitForTimeout
.
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.
Yes, that would be great to fix the other tests so that they don't use waitForTimeout
. Thank you! I filed an issue to track it: #2473
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.
Oh, Thank you for creating a new issue. I will handle it.
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 have added a function to avoid the use of waitForTimeout
.
I hope to get your review.
And I will create a new PR for removing all waitForTimeout
based on this branch.
a160240
to
c218eb6
Compare
What is the new test code for |
Thank you for your review! I want to write a test for I can understand this is a little bit weird. Then I have 3 opinions and I prefer No3 but what do you think?
|
I don't think we should need to add a |
c218eb6
to
4df87fd
Compare
Hum.... Anyway now this PR doesn't need any waiting process except redirect process. And at next PR (#2488),
I hope I will get your opinion about it.
|
packages/kit/test/apps/basics/src/routes/redirect-on-load/_tests.js
Outdated
Show resolved
Hide resolved
packages/kit/test/test.js
Outdated
|
||
// If redirecting, sometimes below error comes. Therefore wait until redirect. | ||
// "page.evaluate: Execution context was destroyed, most likely because of a navigation." | ||
// MOTE: waitForNavigation is extremely slow so doesn't use. |
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.
// MOTE: waitForNavigation is extremely slow so doesn't use. | |
// NOTE: waitForNavigation is extremely slow so doesn't use. |
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.
although I don't think this NOTE makes sense and I'd probably just remove it. goto
on the previous line waits for the page load
event, which is the same thing waitForNavigation
would do. So it can't be any slower. Maybe the issue is that it's already been awaited for, but then the issue is waiting twice for the same event and not that the method is too slow
I think I'd just remove this line since it adds more confusion than it helps with
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.
Although now I'm confused because I don't know exactly where you were going to call waitForNavigation
. The other option might be to move that comment to be right above the line where you might use it
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.
But In most cases, the test failed due to the bellow error without this change.
.svelte-kit/output/client/service-worker.js 9.25 KiB / brotli: 2.08 KiB
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • ✘ • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • (232 / 233)
FAIL build:basics "redirect-on-load [js]"
page.evaluate: Execution context was destroyed, most likely because of a navigation.
at Object.handler (file:///C:/Users/baseballyama/Desktop/git/svelte-contributes/kit-2424/kit/packages/kit/test/test.js:201:29)
at async Number.runner (file:///C:/Users/baseballyama/Desktop/git/svelte-contributes/kit-2424/kit/node_modules/.pnpm/uvu@0.5.1/node_modules/uvu/dist/index.mjs:77:5)
at async Module.exec (file:///C:/Users/baseballyama/Desktop/git/svelte-contributes/kit-2424/kit/node_modules/.pnpm/uvu@0.5.1/node_modules/uvu/dist/index.mjs:131:33)
at async main (file:///C:/Users/baseballyama/Desktop/git/svelte-contributes/kit-2424/kit/packages/kit/test/test.js:394:2)
I think this is similar to microsoft/playwright#4192.
And I can't move this waiting process to redirect-on-load
test file.
Because this error comes before called callback
function.
But I have modified the code in response to the comment below that you gave me.
Could you please check the updated code?
packages/kit/test/test.js
Outdated
break; | ||
} catch (e) { | ||
if (!(e instanceof Error) || i === max) throw e; | ||
await new Promise((resolve) => setTimeout(resolve, 10)); |
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 didn't understand in the NOTE above where you were suggesting the waitForNavigation
might be called. I think that this would be a good place to do it though as an alternative to calling setTimeout
. I'd prefer not to call setTimeout
if possible
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.
Ah Definitely! I should update it!
[This is just additional explanation]
If error comes during await context.pages.js.evaluate(() => window.started);
,
it means already navigation was changed.
So after call await context.pages.js.waitForNavigation();
,
await context.pages.js.evaluate(() => window.started);
should be succeed.
(But run a for loop in case of multiple redirects.)
thank you!! |
FIX: #2424
I simply implemented it according to the comments of #2424.
And I think it works well.
But I'd like to know if there's anything I haven't considered.
Question
If there are multiple redirects, what should I do?
redirect: (redirect && redirect.loaded) ? redirect.loaded.redirect : undefined,
=>
I think mainly this is a programming mistake.
So it doesn't need to handle it.
But it might be kind to throw an error if multiple redirects are there.
Thank you!
Before submitting the PR, please make sure you do the following
Tests
pnpm test
and lint the project withpnpm lint
andpnpm check
Changesets
pnpx changeset
and following the prompts. All changesets should bepatch
until SvelteKit 1.0