* introduce a Controller for requests
* introduce result sorting mechanism
* extend Comments to retrieve commentors (actors) in a tree
* add commenters sorter
* add share recipients sorter
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
Firefox and Chrome drivers for Selenium refuse to click on an element if
the point to be clicked is covered by a different element, throwing an
UnknownError exception with message "Element is not clickable at point
({x}, {y}). Other element would receive the click: {element}". Although
in general that would be a legit error (as the user would not be able to
click on the element) due to a bad layout, sometimes this can be just a
temporal issue caused by an animation, in which case there would be no
problem once the animation finished and the elements are all in their
final location.
Unfortunately, automatically handling those situations in which the
problem is caused by an animation by just retrying a few times if the
element to be clicked is covered before giving up would probably cause
confusion instead of easing test writing.
The reason is that if the center of the element is covered by another
one the Firefox driver for Selenium tries to click on the corners of the
element instead. The problem is that the coordinates used for the click
are integer values, but Firefox has sub-pixel accuracy, so sometimes
(depending on which corner is not covered and whether the left, top,
width or height properties of the element to be clicked have a decimal
component or not) the clicks silently land on a different HTML element
(and that is with squared borders; with round borders they always land
on a different HTML element. That was partially addressed for Selenium
3.0 by clicking first on the edges, but it would still fail if the
middle point of the edges is covered but not the corners).
It is not possible to fix or even detect all that from the tests (except
maybe with some extreme hacks involving accessing private PHP members
from Mink and bypassing or replacing the standard JavaScript executed by
the Firefox driver with a custom implementation...), so it is not
possible to ensure that clicks during an animation will land on the
right element (in fact it is not possible even on static elements,
although except when the layout is wrong there should be no problem);
sometimes retrying a click when the element is covered would solve the
problem, sometimes it would cause a different element to be clicked (and
sometimes there would be even no retry, as the first click would have
silently landed on a different element than the expected one).
Therefore, a different approach must be used. Instead of trying to
automatically handle clicks during animations the tests must be written
being aware of the problem and thus waiting somehow for the animations
that can cause a problem to end before performing the clicks.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Now that the checkbox was moved to its own column clicking on the
thumbnail should behave like clicking on the file name. To achieve this
the left position was replaced with a padding, so the element is kept at
the same place while extending its clickable area to cover the
thumbnail.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The selection column is not only a visual column, but also a real column
of the file list table. Unlike other columns whose width is reduced in
space constrained screens the selection column must stay the same so the
tapping area is large enough to be easily usable
The selection column does not appear in the search results table, so its
contents have to be explicitly aligned with those of the main table
based on whether the main table has a selection column or not (using the
"has-selection" CSS class in the same way as the "has-favorite" CSS
class was being used when there was a column for favorite actions).
In the tests the ":visible" selector can no longer be used. That
selector matches elements with a width or height that is greater than
zero, but the dimensions calculated in the unit tests are not reliable;
the width of the link was zero before these changes, and now moving the
checkbox to its own column causes the height of the link to become zero
too, so it no longer matches the ":visible" selector even if it is not
hidden. As hidding and showing the link is based on its "display" CSS
property its value is the one checked now.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The "has-favorites" CSS class is no longer used after moving the
favorite mark to the top right corner of the thumbnail, so there is no
need to add it to the table.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The favorite icon was shown on its own "column" (not a real column in
the table, but a visual column achieved through margins and left
positions). Now the icon was moved to the top right corner of the file
thumbnail, and the thumbnail and file name were moved to the left to
fill the space left by the "column".
To keep the markup in line with its visual representation (and to ease
the placing through CSS), the favorite mark is no longer prepended to
the row, but appended to the thumbnail instead. In the same way, the
thumbnail is no longer appended to the checkbox label, but to the link
with the name of the file instead (although the checkbox is still shown
at the bottom right corner of the thumbnail, and clicking on the
thumbnail still selects the file). In order to show the "busy" state on
a file the "icon-loading-small" CSS class is set to the parent element
of the thumbnail, so the thumbnail is also wrapped now by another div
with the same size and position as the label.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The checkbox is not shown always with full opacity, though, in order to
reduce the visual noise (specially later, once the checkbox is moved to
its own column).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This is a preparatory step for a following commit in which the position
of the favorite icon and the checkbox will be swapped; in that new
design the favorite icon is no longer expected to be an action but just
a simple mark on whether the file is favorited or not (the action is
expected to be triggered then only from the file actions menu).
The favorite icon is now fully shown or completely hidden depending on
whether the file is favorited or not. As the icon is just informative
but no longer an action now it does not change when hovered or focus. In
the same way, the alternative text when the file is not favorited now it
is not "Favorite" (an action) but "Not favorited" instead.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Currently a file can be favorited either through the inline action or
through the file actions menu. However, the inline action will be
removed in a following commit and then it will be possible to do it only
through the file actions menu.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The new FileAction for the menu is essentially the same as the old
inline FileAction, except for the rendering; in this case the FileAction
is shown in the menu in a standard way, so there is no need to provide a
custom renderer (although the menu entry text and icon change depending
on whether the file is currently a favorite or not, but that can be done
just with displayName and iconClass functions).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Icon class function properties make possible to render a different icon
class depending on the context of the file action.
Inline file actions had support for them already and called them passing
the file name and context of the file action as parameters. Due to this
the FileActionsMenu passes those parameters too to icon class functions
instead of just the context like done for display name functions.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
