Fix dashboard front-end shenanigans #64
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Apparently this broke, or was already broken. Setting the hours, minutes and seconds was not properly triggering the JavaScript events that update the actual duration in seconds for this field. The JavaScript event has been replaced with a new submit event that updates the value for the duration in seconds just before submitting the form. Alternatively, it has been thought to simply make the backend controller accept the duration sexagesimal components.
The duration component in the video form actually requires testing that the JavaScript code the page uses to convert the duration from sexagesimal units to seconds actually works. Apply this commit to add support for Poltergeist, a library that makes use of PhantomJS to run some feature tests in a real browser with JavaScript support, unlike the default browser used by Capybara. This is used to fix some new regressions found in dashboard/videos.js.
If the app_host and the server_port don't get reset after running the dashboard tests that actually need those values set, the remaining tests will be run using the same app_host. Forgetting about this will make all the remaining public site feature tests to fail because, given that app_host still points to the dashboard, they will run the tests against the dashboard instead of against the public site. Apply this commit to fix this by clearing the values for Capybara.app_host and Capybara.server_port after running the tests. The values are set to nil because after running a debug puts these seem to be the default values (unlike default_host).
Integration tests are failing because Travis uses PhantomJS 1.9.8, which doesn't properly understand the Funtion.prototype.bind method, causing the Webpack output to fail. It's a known issue and until Travis updates PhantomJS to 2.x (something they have been promising for two years) the only choices are: to either use a polyfill for ancient browsers who still don't understand ES5 (including PhantomJS 1.9.8), or to get a PhantomJS 2.x binary, which is my proposed solution.
Supposedly upstream Webpacker has had a commit for a few days where the dev server is automatically launched in testing environment as well.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Some of the JavaScript code used for the duration component in the dashboard video editor seem to have regressions, possibly introduced in #63 during the port to vanilla JS.
Anyway, JS hasn't ever been tested. This PR should also fix that by adding support for a JavaScript engine in Capybara and using it instead of the default stack when running some feature tests for pages that depend on JavaScript to work.