-
Notifications
You must be signed in to change notification settings - Fork 320
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
Failure on native date input on subscribing user to newsletter #70
Comments
…8.0.5 Try Travis CI build with latest firefox 38.0.5, attempt at replicating bug #70
@leesmith I think that particular failing spec ran against PhantomJS - do you happen to know what version of PhantomJS you've got installed in this environment? |
I'm using phantomJS 2.0.0...as installed via Homebrew for OSX. |
I don't guess you were able to replicate this? So for this specific test, when I inspect the params in the create action of the subscriptions controller, "Start date" is not being set to what the test code is trying to set it to (Jan. 1st). I always get today's date on the controller side, which I'm guessing is the default value for that form field... |
Is there a reason you're specifically using selenium-webdriver? Doesn't poltergeist run a headless webkit browser in the background? Wouldn't that be preferred over the selenium/firefox combo? This test still fails for me, btw. |
Apologies for being slow to respond to this. There's a couple reasons using both a headless and real browser:
I've got some time now to try replicating the issue, I'm on an older phantomjs currently so that might explain the difference. |
Tried the spec in phantomjs 1.9.8 ( |
Homebrew needed updating:
Now phantomjs 2.0.0 is installed and replicating the failure!
|
Using Modernizr to test if phantomjs supports native date input:
I've wrongly had the I'm not sure why the test was passing with 1.8.1 and 1.9.8. Regardless, the test with those browsers is misleading. It claims to test native date inputs but it is not. Chrome supports native date inputs so this I'm thinking chrome ought to be brought back into the project and used in this test. |
Forgot to mention, this also signifies the test for native date input support in |
When bringing Chrome back into the project, it'll also need to be configured on TravisCI. There appears to be a way now for this to work. At least here's one option: travis-ci/travis-ci#938 (comment) |
When bringing chrome back, see
|
In addition bring back chromedriver:
|
@leesmith Thanks for bringing this to my attention and sorry it's taken a while to get round to digging in. I'm not sure when I'll get a chance to fix it I'm afraid. |
No problem! This is quite a tricky test to accomplish I guess since browsers handle native date inputs differently. I've never had to test that so it's interesting to me. Great work! |
@eliotsykes does this mean there's currently not a suitable example of how to test features with both native and javascript-popup-style date input fields? |
@amnesia7 subscribe_to_newsletter_spec.rb shows how you could test both native/non-native date inputs, though its not working at the moment :-( To get it to work would involve configuring a browser in the project that truly does support native date input (such as Chrome), then adding that browser's driver to the start of the |
@eliotsykes if I changed my setup to use poltergeist normally and chromedriver for native date input tests do you know how you to interact with the native date input in a test? Is there anything special about it? |
@amnesia7 My guess is that you won't be able to interact directly with clicking/tapping the native date input controls. In that case, I'd assume the native date controls work as intended and not take responsibility for testing them. You might be able to use something like this to fill in the date: fill_in "Start date", with: "01/01/2015" (If that doesn't work, it might be worth tweaking the date format in the |
I'm on OSX 10.10.3, Firefox 38.0.5. It looks like the date input is not being recognized and falling back to today's date, which is not what the test is expecting.
The text was updated successfully, but these errors were encountered: