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.
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.
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.
Note that we keep :created_at order as complement to new :order field.
We do this so that current installations will not notice any change in the
sorting of their cards when upgrading, as the default "order" field will always
be 1, so it will continue to sort by the "created_at".
We are ensuring that only position field is rendered only on
non-header cards.
Note that we have 3 sections that use widget cards:
- Homepage (cards and header cards)
- Custompages (only have cards)
- Sdg Homepage (cards and header cards)
This test is failing often due to an "Unable to autoload constant"
error, that will be fixed after switching to zeitwerk.
Just like it happened in the the "Polls can be listed" test, the reason
seems to be accessing a page containing several ActiveStorage
attachments. However, since this test only makes sense when two or more
images are displayed on the page, we can't change the test so create
just one image.
So, for now, we're commenting the test, and we'll uncomment it again
when we enable zeitwerk in version 2.2.0.
Creating records after starting the browser with the `visit` method
sometimes results in database corruption and failing tests on our CI.
Splitting some tests or merging them together solves the issue.
When running these tests, under certain conditions, we get a warning
followed by an error:
```
activesupport-6.1.7.7/lib/active_support/dependencies.rb:502:
warning: already initialized constant ActiveStorage::Representations
activesupport-6.1.7.7/lib/active_support/dependencies.rb:502:
warning: previous definition of Representations was here
Failure/Error: raise LoadError, "Unable to autoload constant
'#{qualified_name}', expected #{file_path} to define it"
LoadError: Unable to autoload constant
ActiveStorage::Representations::RedirectController, expected
activestorage-6.1.7.7/app/controllers/active_storage/representations/redirect_controller.rb
to define it
```
The error seems to take place when we request a page in a test that
loads two (or more) ActiveStorage images if ActiveStorage hasn't loaded
yet, although it's a flaky error and so the test doesn't always behave
like this.
We've tested that switching to zeitwerk solves the issue but, since we
aren't switching to zeitwerk in version 2.1.1 and we'd like this version
to run all tests correctly, for now we're changing the tests so they
don't load two records with images.
On of these tests ("Polls Index Polls can be listed") fails on my
machine when run individually. I haven't been able to consistently
reproduce the other ones.
When we create a budget heading through factories it's placed at Puerta del Sol,
Madrid. It seems reasonable that the `map_location` factory places the points near
there.
Before these changes sometimes the map center was placed in Madrid while map
locations were placed in Greenwich, therefore markers were not visible in the
map current pane.
Before this change, two important things depend on the format of each key,
where to render it in the administration panel and which kind of interface
to use for each setting. Following this strategy led us to a very complex
code, very difficult to maintain or modify. So, we do not want to depend
on the setting key structure anymore to decide how or where to render each
setting.
With this commit, we get rid of the key format-based rules. Now we render
each setting explicitly passing to it the type and the tab where it belongs.
This way only verified users will be able to access this page, which
shows the username of the receiver of the direct message. With this,
it's no longer possible for unverified users to browse direct message
URLs in order to collect usernames from every user.
In order to test that we remove metadata from PDF we need add
"pdf-reader" gem.
With this gem we can check the info from the PDF and ensure that
this info is removed.
This rule was added in rubocop-capybara 2.19.0. We were following it
about 85% of the time.
Now we won't have to check both have_css and have_selector when
searching the code.
In the admin section, when clicking on a link that leads to a page in
the public area, sometimes the page was opened in the same window and
sometimes it would open in a new window, with no clear criteria
regarding when either scenario would take place.
This was really confusing, so now we're more consistent and open
(almost) every link in the same window. The main reason behind it is
simple: if we add `target: _blank`, people who want to open those links
in the same window can no longer do so, so we're taking control away
from them. However, if we don't add this attribute, people can choose
whether to open the link on the same tab or to open it on a new one,
since all browsers implement a method to do so.
More reasons behind this decision can be found in "Opening Links in New
Browser Windows and Tabs" [1].
We're keeping some exceptions, though:
* Opening the link to edit an investment on the same tab would result in
losing all the investment filters already applied when searching for
investments, so until we implement a way to keep these filters, we're
also opening the link to edit an investment in a new tab
* For now, we're also opening links to download files in a new window;
we'll deal with this case in the future
[1] https://www.nngroup.com/articles/new-browser-windows-and-tabs/
Out of the usability issues I've experienced when using Consul
Democracy, the biggest one has arguably been the fact that the link to
edit a proposal opens in a new tab. I guess the reasoning behind it is
that the page to edit a proposal is not part of the proposals dashboard,
but what the hell! Imagine if every link to edit something opened in a
new tab...
So we're reducing the impact of this nonsense by opening most dashboard
links in the same window; for now, we're still opening in a new window
links to download files and links that might point to external websites.
We'll address those ones in the future.
We used to open these links in new tabs, but accidentally stopped doing
so in commit 75a28fafc.
While, in general, automatically opening a link in a new tab/window is a
bad idea, the exception comes when people are filling in a form and
there are links to pages that contain information which will help them
fill in a form.
There are mainly two advantages of this approach. First, it makes less
likely for people to accidentally lose the information they were filling
in. And, second, having both the form and a help page open at the same
time can make it easier to fill in the form.
However, opening these links in new tabs also has disadvantages, like
taking control away from people or making it harder to navigate through
pages when using a mobile phone.
So this is a compromise solution.
Quoting usability experts Jakob Nielsen and Anna Kaley [1]:
> [Opening PDF files in new tabs] is problematic, because it assumes
> users will always do the exact same things with certain file formats,
> which isn’t always the case.
There are many examples of this situation. For example, some people
(myself included) configure their browser so it downloads PDF files
instead of opening them in the browser. In this situation, a new tab is
opened, a blank page is displayed, the file is downloaded, and then
either the tab is closed or the blank page needs to be manually closed.
The end result is really annoying.
Other situations include people who use a mobile phone browser, where
navigating through tabs is generally much harder than doing so on a
desktop browser.
But IMHO the most important point is: every browser already provides a
way to open "regular" links in a new tab, so people can choose what to
do, but if we decide to open the link in a new tab, we take control away
from them, and people who'd like to open the link in the same tab might
feel frustrated.
In these cases, the links either say "download" or include the word
"PDF", so people know in advance that they're going to download/open a
PDF file, and so we're giving them information and, by removing the
`target` attribute, we're giving them control over their browser so they
can choose what's convenient for them.
[1] https://www.nngroup.com/articles/new-browser-windows-and-tabs
We were displaying documents in five places, and in five different ways.
Sometimes with the metadata in parenthesis after the title, sometimes
with the metadata below the title, sometimes without metadata, sometimes
with an icon in front of the document, and sometimes with a separate
link to download the file.
So we're now displaying the same thing everywhere. Not sure whether this
is the best solution, but at least it's consistent.
We aren't unifying the way we display a list of documents, though, since
different sections look pretty different and I'm not sure whether the
same style would look well everywhere.
Note that we're renaming the `document` HTML class in the documents
table to `document-row` so the styles for the `document` class don't
apply here.
We were using a "Download file" link in one place, while in another
place we had an additional column where the name of the document was a
link to download it.
There's a link next to it that does the exact same thing and includes
the word "download", which was confusing in some cases since people
might think that links with different texts lead to different pages.
