Extract the needed portion of code to a new partial to be able to update
only the elements needed when a new comment is added keeping UI properly
updated.
In this case the confirmation dialog isn't really necessary since the
action to enable/disable the setting can easily be undone.
Furthermore, these tests were failing with Chrome 83, probably because
we use `confirm_dialog` and then we use `visit` without checking the
page in between.
In theory we shouldn't need to check the page in between because the
request generated by `confirm_dialog` is a synchronous one and so
`visit` isn't executed after the previous request has finished, but
apparently this behavior has changed in Chrome 83.
We could add an expectation before executing the `visit` method, but
that wouldn't improve the usability of the application.
The number of errors in a form includes several errors for the same
field. For example, if a title is mandatory and has to have at least 5
characters, leaving the title blank will result in two errors. So users
will be invited to look for two errors, but they'll only find one field
with errors.
So it's a bit more intuitive to show as many errors as fields having
errors.
Note we're excluding errors on `:base`, which is a bit of a hack for
errors in association fields. For example, if the title of one
translation is not present, `resource.errors.messages` will contain two
elements: one for the translation's title, and one for the `base` field.
This resulted in the count of errors being 2 when there was only one.
Also note I haven't found a way to count errors on all `has_many`
relations. That is, if two translations have a missing title field, only
one error will be mentioned in the message (as it did before this
commit).
We were using a <ul> tag for a single comment, where the first element
of the list was the comment itself and the second element was the list
of replies.
IMHO it makes more sense to have a list of all comments, where every
element is a comment and inside it there's a list of replies.
We're also rendering the list even if it has no children so it's easier
to add comments through JavaScript. Then we use the :empty CSS selector
to hide the list if it's empty. However, since ERB adds whitespace if we
structure our code the usual way and current browsers don't recognize
elements with whitespace as empty, we have to use the `tag` helper so no
whitespace is added.
Tests are also a bit easier to read, even though we need to use the
`text:` option to find links because otherwise the text in the hidden
`<span>` tags will cause `click_link` to miss the link we want to click.
Here's an explanation by one of Capybara's authors:
https://github.com/teamcapybara/capybara/issues/2347#issuecomment-626373440
When a page with ckeditor is restored from browser cache by using browser
history back feature application was trying to re-initialize it but this was
throwing some javascript errors that left ckeditor useless. The ckeditor user
interface seemed to be loaded correctly but editor contents was not shown
and ckeditor locked.
This solution is about destroying all ckeditor instances on page before
leaving it and force the reinitialization after Turbolinks restored the cache.
Inspiration here [1].
There is a similar patch to make it work with Turbolinks 5.x versions [2].
[1] https://github.com/galetahub/ckeditor/issues/575#issuecomment-132757961
[2] https://github.com/galetahub/ckeditor/issues/575#issuecomment-241185136
We were calling initialize_modules after every ajax call only to apply the
application javascript to new elements added though ajax calls, this is not
always needed because some ajax calls do not add new elements to the user
interface so there is no new elements to initialize. This technique was working
fine in most cases but was causing different kind of problems at some pages where
some elements where being unnecessarily reinitiliazed causing the execution of the
element associated scripts as many times as the element was initialized. This fix
should relief a little bit of work to users browsers.
After this change we had to fix some pieces of javascript:
Regarding LegistationAnnotatable module, since we are not re-initializing Annotator
app we cannot destroy it so now we only need to insert the new annotation into annotator
interface to keep it properly updated.
Regarding Comments module, we do not need anymore the initialization check because this
code only will be fired once now we do not launch application initialization after ajax
calls. Also, when a new comment is created its added to the DOM through AJAX and include
some elements that needs javascript initialization to work. By using
"Delegated event handlers" [1] new comments will be initialized automatically when added.
[1] https://api.jquery.com/on/#direct-and-delegated-events
Some specs involving CKEditor were failing sometimes in the Rails 5.1
branch. The reason why these specs pass with Rails 5.0 but fail with
Rails 5.1 are unknown. On my machine the tests pass when precompiling
the assets, which makes me think it's related to the way Rails handles
them, but it might have nothing to do with it.
The only (apparently) 100% reliable solution I've found is to wait for
CKEditor to load before trying to fill it in. After running the tests on
my machine hundreds of time, I didn't get a single failure.
Using `render :nothing` was deprecated, but we never noticed it because
we didn't have a test for the action using it. In Rails 5.1, it raises
an exception.
Using `head :ok` and adding a test for this scenario solves the issue.
CKEditor repositions the dialog to attach an image after showing it. If
its position changes right when Capybara is trying to click the "Upload"
link, the click does not work properly.
I haven't found a way to check the dialog has stopped moving, so I've
chosen to force its position to the top.
Without this change, this test failed a lot on my machine when using
Rails 5.1, both with an "iframe ckeditor" and an "inline ckeditor".
However, it didn't fail when using Rails 5.0.
We were manually setting `http://www.example.com`. However, Capybara now
uses `http://127.0.0.1`.
While we could change the code to use `127.0.0.1`, I think directly
using `Capybara.app_host` makes it easier to realize what the code is
doing. And, particularly, now it's clear the host has nothing to do with
our `Setting["url"]`, which by default points to `www.example.com` as
well.
