Selecting the tom select option in the dropdown often happened quicker
than the search finished. In that case we selected the option from the
list of all options and then the search would present the found option
again and leave the dropdown open.
This didn't cause any trouble in the past because any other action would
close the dropdown again. But the new cuprite version didn't trigger the
next click on the target element. It would just close the dropdown on
the next click without further action. That would then break the next
assertion looking for the next open dropdown, which didn't open with the
click.
Selecting the "active" option means that we wait for the search to
finish and present an option as active. Clicking that option closes the
dropdown without opening it again.
- Implemented apply_tags_filter method to handle "None" option in tag searches.
- Updated tags select field to include "None" option in the filters.
- Enhanced search_by_tag method in specs to accept multiple tags and raise an error if none are provided.
- Added tests for searching by "None" tag and combinations with other tags.
Rails 4.1 added time helpers but we never bothered using them. But now
I'm getting rid of the Timecop dependency and use standard helpers.
Beware though that the new helpers always freeze time. When you travel
to a certain date then the clock stops ticking while Timecop maintained
the passing of time.
The freezing of time could cause problems if you are trying to enforce a
timeout. But all current specs don't seem affected.
In most cases, the freezing will make it easier to avoid flaky specs.
Apparently, Rake's way of reloading the task code confuses the code
coverage report. Code tested by rake task specs was not recognised as
covered even though it was.
The new default dates were not aligned with the assumption that the
datepicker would open on the current date. The datepicker helper would
try to navigate to the previous month or next month in relation to the
reference date. Now with the wrong reference date, it would infinitely
go into the past or future, not finding the right year and month.
I chose a more robust approach of setting the year and month directly
which the user can do as well. Then we don't need a reference date.
