Note that the click_link "Reply" is now inside a "within".
This is due to the case of "legislation_annotation" before in the original test
no comment was created as it simply took the one created by default when creating
a "legislation_annotation".
```
annotation = create(:legislation_annotation, author: citizen)
comment = annotation.comments.first
```
Now to try to unify this test, we always create a comment, and in this case as we
also created the "legislation_annotation" we have 2 comments, so it is necessary
to add the "click_link" inside the "within".
Note that, in all cases except in :legislation_annotation, the behavior for
click_link is now slightly different.
Previously, the click_link outsite of within block meant that we made sure there
was only one link with that text in the whole page. Now, in order to unify this
spec we change the behaviour.
Note we're removing the Performance/StringIdentifierArgument rule
because now it also replaces methods in interpolation, and we don't
particularly prefer using `send(:"#{method}_name")` over
`send("#{method}_name)`. We actually use the latter about two thirds of
the time.
We'll add this rule again if it ever offers the option to ignore the
cases where interpolation is used, although it's highly doubtful that'll
ever happen because this rule is meant for (insignificant) performance
gains and not for code clarity.
Bumps [rubocop-performance](https://github.com/rubocop/rubocop-performance) from 1.19.1 to 1.20.2.
- [Release notes](https://github.com/rubocop/rubocop-performance/releases)
- [Changelog](https://github.com/rubocop/rubocop-performance/blob/master/CHANGELOG.md)
- [Commits](https://github.com/rubocop/rubocop-performance/compare/v1.19.1...v1.20.2)
---
updated-dependencies:
- dependency-name: rubocop-performance
dependency-type: direct:development
update-type: version-update:semver-minor
...
Signed-off-by: dependabot[bot] <support@github.com>
We haven't updated this initializer for years, so here's the updated
version. The `expire_auth_token_on_timeout` doesn't seem to exist
anymore, and a few more options have been added.
Note that the default Devise initializer configures
`config.responder.error_status` and `config.responder.redirect_status`
so they follow Hotwire/Turbo conventions. For now, I'm commenting these
lines because we currently don't use Hotwire/Turbo.
Spring now (since version 3, I think) requires `config.cache_classes =
false` in order to work. However, that means that tests would be slower
for developers who don't use spring (like me).
I'd personally vote for removing spring completely (Rails removed it as
a default installation option in August 2021 [1]), but for now we're
keeping it for backwards compatibility.
[1] See pull request 42997 in https://github.com/rails/rails
While people using screen readers already have keyboard shortcuts to
jump to the <main> tag, there are people who navigate the page with the
keyboard using just the tab key, and for them, this link provides a way
to save time and start reading the main content instead of having to
manually go through all the navigation links every time a new page is
loaded.
Note that we had to add an additional `width: 0` rule because
Foundation's `element-invisible` would apply `1px` and the test checking
for `visible: :hidden` would faile.
Many pages had this tag, but many other didn't, which made navigation
inconsistent for people using screen readers.
Note that there are slight changes in two pages:
* The homepage now includes the banner and the content of the
`shared/header` element inside the <main> tag
* The budgets index now includes the banner inside the <main> tag
I see both potential advantages and disadvantages of this approach,
since banners aren't necessarily related to the main content of a page
but on the other hand they aren't the same across pages and people using
screen readers might accidentally skip them if they jump to the <main>
tag.
So I'm choosing the option that is easier to implement.
Note we're adding a `public-content` class to the <main> element in the
application layout. This might be redundat because the element could
already be accessed through the `.public main` selector, but this is
consistent with the `admin-content` class used in the admin section, and
without it the <main> element would sometimes have an empty class
attribute and we'd have to use `if content_for?(:main_class)` or
`tag.main` which IMHO makes the code less consistent.
The Capybara::DSL monkey-patch is only done on the `visit` method
because it's the only reliable one. Other methods like `click_link`
generate AJAX requests, so `expect(page).to have_css "main", count: 1`
might be executed before the AJAX request is finished, meaning it
wouldn't properly test anything.
We were testing what happens when clicking on a geozone without HTML
coordinates, which won't happen in a real browser.
So we're now defining the HTML coordinates and clicking on the area in
the test, which is what real people will do.
We also avoid having two consecutive `visit` calls, which will interfere
with the way we plan to test the presence of the <main> tag after every
`visit`.
Note that, the test didn't work with the HTML coordinates defined in the
`with_html_coordinates` trait, with Capybara showing the following
error:
```
Selenium::WebDriver::Error::ElementClickInterceptedError:
element click intercepted: Element
<area shape="poly"
coords="30,139,45,153,77,148,107,165"
href="/proposals?search=California"
title="California" alt="California">
is not clickable at point (413, 456).
Other element would receive the click:
<img usemap="#map" src="/assets/map.jpg">
```
The cause of this error was the strange shape of the polygon, which was
greatly concave and and so the middle of its area wasn't part of it.
We're changing the polygon so it's now convex and when Capybara clicks
on its middle point everything will work as expected.
