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

tests: add smoketest for slow service worker #6648

Merged
merged 2 commits into from
Nov 27, 2018
Merged

Conversation

patrickhulce
Copy link
Collaborator

Summary
Curious what types of late service worker we don't catch. I saw @paulirish's comment that it's just calling .register but I was skeptical based on the other reports. I should not have been skeptical it lives up, and this just adds a smoketest to prove it. We wait for delays in loading the service worker script itself and delays in the install event too.

Related Issues/PRs
#2924 (comment)
#5527

}

if (window.location.search.includes('slow')) {
setTimeout(() => registerServiceWorker('?delay=5000&slow'), 500);
Copy link
Collaborator

Choose a reason for hiding this comment

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

would it make any difference to do this on "load", where the load event is deferred by a significant amount of time?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This setTimeout is mostly useless I can actually remove it since it's complicating the understanding of what's going on. Switching to fire on the load event is a good idea 👍

the load event is currently being delayed by an image farther down that takes 2s, the only way LH doesn't catch service worker AFAICT is if the page doesn't call .register quickly enough, and this test was meant to prove that fact.

Copy link
Collaborator

Choose a reason for hiding this comment

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

AFAIK this (registering SW on "load") is basically what pintrest.com (which LH says has no SW) does. not sure if the key difference is how long until "load" fires - or something else entirely.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

If that's all they're doing, then I'm not sure what's going on there. We always wait until load so unless their load event handlers take a very long time such that we don't get to .register in time, then it must be something else.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I can take a look closer at pinterest if there's not already too many cooks in the kitchen :)

Copy link
Collaborator

@connorjclark connorjclark Nov 26, 2018

Choose a reason for hiding this comment

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

There's at most 1 :) IDK if @wardpeet ever started on it.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Haha, alright I'll poke around.

Copy link
Member

@brendankenny brendankenny left a comment

Choose a reason for hiding this comment

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

so just to be clear, the intention is this is a slow case that we do indeed handle and this will ensure we don't regress?

If so, LGTM!

(if not, I don't understand :)

console.log('service worker registration complete');

registration.addEventListener('statechange', e => {
console.log('sw registration is now', e.target.state);
});
}).catch(function(e) {
} catch (e) {
console.error('service worker is not so cool.', e);
throw e;
Copy link
Member

Choose a reason for hiding this comment

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

do we check for this anywhere? Or is the hope that a smoke test will fail and this would be used for debugging.

Maybe we should be pulling in errors-in-console into all our smoke tests :)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

do we check for this anywhere?

nope

Or is the hope that a smoke test will fail and this would be used for debugging.

Bingo!

Maybe we should be pulling in errors-in-console into all our smoke tests :)

Not a bad idea, followup! :D

@patrickhulce
Copy link
Collaborator Author

so just to be clear, the intention is this is a slow case that we do indeed handle and this will ensure we don't regress?

yeppers

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.

None yet

3 participants