This is the reason why this feature was implemented in the first
place: it's easy to open the editor, make some changes, close it, and
continue without realizing the changes have not been saved.
In the rest of the forms, this functionality is quite lacking. For
starters, some forms warn if there are unsaved changes, while some forms
don't, which is highly inconsistent and disorients users.
Furthermore, we were having problems with this feature after upgrading
Turbolinks, particularly in forms using CKEditor. In these cases, a lot
of hacking needs to be done in order to make this feature work properly,
since CKEditor adds some formatting automatically, and if this is done
after the form is serialized, we'll get some unexpected behavior. On the
other hand, comparing the value of a textarea against its `defaultValue`
property will work on every edge case, including using the browser's
back button or reloading the page.
Finally, users are used to the way web forms work, and aren't used to be
asked for confirmation when they change their mind and decide to leave
the page without saving the changes. Asking them for confirmation will
be annoying in most cases. Besides that, if they accidentally leave the
page, they can use the browser's back button and they'll recover the
unsaved changes.
It's true this won't happen it they accidentally close the browser's
window, but our WatchFormChanges functionality didn't work in this case
either. Using the "beforeunload" event adds more problems than it
solves, since it doesn't support custom messages (or, to be more
precise, modern browsers ignore custom messages), and it doesn't get
along with turbolinks.
Co-Authored-By: Senén Rodero Rodríguez <senenrodero@gmail.com>
We were using `overflow: scroll` as a workaround with a problem we had
with the equalizer. But now we never need an extra vertical scroll bar,
and we only need an extra horizontal scroll bar on small screens.
Since the dashboard was using the class `admin-content` as well, we need
to apply to the dashboard the same changes we've done in the admin
section. I've extracted them into a mixin.
In some situations where JavaScript makes content disappear, the height
of the element calculated by foundation's equalizer isn't recalculated,
leaving blank space at the bottom of the page. I've seen cases where a
blank vertical space of 2000 pixels is on the page.
Using flexbox solves the problem, since CSS takes care of everything.
There's a flaky test creating a group for a budget which takes place
because toggling a form using jQuery sometimes results in the button not
being correctly clicked by Capybara.
Checking the page with `expect(page).to have_button 'Create group'`
before clicking the button doesn't solve the problem; it looks like in
those cases Capybara waits for AJAX requests but not for JavaScript
animations.
See also issue #2573.
Why:
* There is a data-equalizer attribute on the parent div, and a data-equalizer-watch on a sibiling div, and that breakes both the purpose of those values (Resize child elements of data-equalizer to have the same height. Ref: http://foundation.zurb.com/sites/docs/equalizer.html)
* That lack of attribute was breaking many specs consistently on localhost with phantomjs 2.1.1 on macos sierra (and ubuntu as reported by @amaia)
How:
* Just adding the missing 'data-equalizer-watch' attribute on the div child of the one using 'data-equalizer'
