Capybara helpers already wait for the content to show up (and we already
have a default of 10 seconds configured), so I don't think waiting more is
actually the problem in these specs.
But if we wanted to wait more, I think it's better to pass the `:wait`
option to capybara matchers, because that's a "maximum waiting value"
but we'll still proceed earlier if the content shows up.
Using the same idea, I changed the positive assertions to happen first,
because negative assertions do spend "max wait time" waiting, while
positive assertions only wait until the content shows up.
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.
Rewrite the loop "break unless a = order.next! while !order.delivery?" to correct the offenses. Not adding a helper because the change was only needed in a couple of places.
It looks like we have a new race condition that may only be a problem in
specs. If you trigger one report, it displays via websockets and then
you trigger the next report, there may still be some Javascript active
that displays the first report while the second one is loading. I'm not
sure if users would navigate that fast though.
To minimise the problem, I adjusted the polling to leave more room for
the default websockets response.
This also resolves a race condition scenario. Even if the report gets
rendered via websockets before the controller response is rendered then
the fallback script loads the report again. It's not the most beautiful
but probably okay until we replace websockts altogether.
I'm leaving websockets in at the moment because it can render the report
much quicker than polling can.
I'm adding TurboPower for the scroll_into_view action. It adds all the
nice CableReady actions to Turbo Streams.
Note that I omitted `block: "start"` because that option is the default
in Javascript. And the generic `action` method doesn't support
parameters like this anyway. I'll work on that in the next commit.
I also re-introduced a race condition by rendering the "loading"
indicator after triggering the report rendering job. I'm planning to
resolve that later.
Sending large reports via Cable Ready is unreliable. The events are
dropped at an unknown point and the report is never displayed to the
user. Instead we just send a link to the report via Cable Ready and
offer a button to load the report on screen.
This has the UX benefit of warning the user about the size as well.
Weaker devices can struggle rendering big HTML documents.
We had a race condition that could first display the report and then
replace it again with the "loading" spinner. That doesn't seem to happen
now that we changed the order of cable events.
I'm hiding a real bug here. There's a race condition when the cable event of
the finished report is sent before the loading spinner rendered. The
spinner then overwrites the report again. I added a spec for that but
don't have a solution yet.
I also noticed that the loading spinner is not displayed in testing but
we can assert on the CSS class of the container.
