Plyr: proposal: unit tests for browsers

[DanielRuf]

I would like to see actual browser based unit tests and would like to help with this.

I recommend using mocha with puppeteer like we do at https://github.com/zurb/foundation-sites

To be exact mocha-headless-chrome + mocha + chai.

[sampotts]

This would be great. I'll start taking a look into it.

[DanielRuf]

And jest-puppeteer could be also a solution. I'll check them all to see which are better for testing (performance, maintenance, issues, platform support, ...).

[sampotts]

Thanks mate, any help is appreciated!

[gurupras]

I have reasonably good experience with puppeteer if we do end up going that way. I'm not very good at writing stuff from scratch, but if someone can come up with a basic framework for doing this, I'm sure I can help quite a bit.

[DanielRuf]

@gurupras any support is very appreciated.

I'm currently finishing a very short introduction article about the mentioned solutions, it might be probably helpful.

[friday]

Something that would benefit a lot from testing is the different events and states. I've been working to improve this in a recent PR, but haven't got a full picture other than that it's still lacking (not consistent and/or following the standards). HTML5 obviously is pretty spot on (except the progress event since the w3c spec pretty much leaves it up to interpretation). YouTube and Vimeo aren't though. The Plyr progress "slider" doesn't pause when you seek like native browsers do http://jsbin.com/jutiveyefa/edit?console,output, and also doesn't set currentTime before the seeking event for youtube and vimeo.

It's also super easy to get it wrong, and hard to "proof read" the entire debug log. And it may still come off as "working" unless you test very thoroughly.

I think the tests could also be reused, since the same should apply regardless of provider (html5, vimeo, youtube), and in the future with plugin support it should be really helpful to plugin developers too.

[sampotts]

but haven't got a full picture other than that it's still lacking (not consistent and/or following the standards).

Could you expand on this perhaps? What standards?

except the progress event since the w3c spec pretty much leaves it up to interpretation

Personally I think is the naming is a little strange and trips people up but it's consistent with XHR. Other than the name it works fine IMO. It's fired periodically as data is downloaded. How would it be improved?

It's not something we have control over anyway and getting the browser devs to fix even minor bugs is painful at best. I've been trying to get Safari to fix a bug where custom styled <input type="range"> elements are constantly redrawn after interaction and getting no where. You'd think wasted CPU/GPU cycles would be an issue?!

The Plyr progress "slider" doesn't pause when you seek like native browsers do

We don't have to mimic _everything_ the native players do. We should decide what's best. Remember the browser devs don't always make the best decisions. In this case though, would this be pause on mousedown/touchstart and then set currentTime and play on mouseup/touchend?

[friday]

Could you expand on this perhaps? What standards?

HTML5 media events (since we're mainly using the same events now)

• https://dev.w3.org/html5/spec-preview/media-elements.html#mediaevents
• https://dev.w3.org/html5/spec-preview/media-elements.html#seeking (there is a 14 bullet list for seeking).

The w3c specs are quite detailed with the order of the events and states etc. The MDN docs only covers the basics.

I mainly noticed the order being wrong for the play/pause events and the paused state, and seeking and currentTime. There might not be that much more, an I'm sorry to come off as critical to your work. The main point is without tests I wouldn't consider to "know" this or "have a complete picture". I think adding tests for this will reveal some blindspots, like when you first started using static code analysis (linting). And I think it's also super easy to accidentally break the events without tests.

Personally I think is the naming is a little strange and trips people up but it's consistent with XHR. Other than the name it works fine IMO. It's fired periodically as data is downloaded. How would it be improved?

Our current event handler for the buffer progress (which also handles some other ui update) is listening for playing and progress. If progress was triggered consistently as the media is buffered this wouldn't be needed, and these could be separated. For vimeo progress is also triggered falsely (as mentioned in that thread).

It's not something we have control over anyway and getting the browser devs to fix even minor bugs is painful at best. I've been trying to get Safari to fix a bug where custom styled elements are constantly redrawn after interaction and getting no where. You'd think wasted CPU/GPU cycles would be an issue?!

No, I mean we should "fix" the inconsistencies on the event level in our provider objects. In the worst case scenario we can use setInterval and trigger event on changes for example (like for youtube).

And I do think wasted CPU/GPU cycles is something they care about. I couldn't comprehend the insane amount of work they have to deal with.

In this case though, would this be pause on mousedown/touchstart and then set currentTime and play on mouseup/touchend?

Yes. That way the handle won't get pulled away as you're dragging it and you won't get the clippy audio sounds.