This ensures that the resize tests do not depend on the values set in
the CSS files.
Note that this change causes a test to fail with Firefox, but not with
PhantomJS. This is due to a difference in the starting width used by
Firefox and by PhantomJS, and it will be fixed in a following commit.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the parent element of the breadcrumbs was resized to a larger width
and the siblings of the breadcrumbs expanded to fill all the available
width some crumbs could be hidden even if there was enough room for
them. The reason was that the width of the siblings being used to
calculate the available width for the breadcrumbs was the expanded width
of the siblings. Now as many crumbs as possible (that is, fitting in the
parent, no matter the siblings) are first shown so the expanding
siblings are compressed before calculating the available width.
Due to the lack of support for flexboxes in PhantomJS the related unit
test is skipped; it has to be run in other browser, like Firefox.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Other apps could add elements to the controls outside the creatable
actions div (for example, the button to switch to the gallery), so the
widths of all the visible siblings of the breadcrumbs have to be taken
into account in the size calculations.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
There are some differences in width handling between the browsers used
to run the tests, most likely due to their support (or lack of) of
certain CSS features: PhantomJS requires "width" to be set (probably
because it does not handle flex displays and treats it like a block, so
"min-width" does not matter in this case), while Firefox requires
"min-width" to be set (otherwise the children of "#controls" could be
compressed due to its use of flex display and the elements would end
with a different width than the one needed for the tests). Due to all
that the width of the breadcrumb siblings must be specified in the tests
using both "width" and "min-width".
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
There is no need to call "setDirectory" again in resize tests; it is
enough to simply resize them (and isolates them better to just test the
resizing behaviour).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The "usedWidth" attribute was not used elsewhere outside the "_resize"
method, so it was replaced with a local variable. Moreover, it was also
renamed to a more suitable name ("availableWidth").
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Setting the width of the parent element of the breadcrumbs and then
explicitly calling "_resize" is enough to test the resizing behaviour.
This makes possible to remove the "setMaxWidth" method and its related
code, which was used only for testing purposes.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The new 'Move and copy' operation from #6040 requires UPDATE permissions
on the selected files. However, READ would be sufficient to create a
copy of a file (if not viewed as a public share). For this reason this patch:
- changes the permission of the 'MoveCopy' action to PERMISSION_READ
- changes the label of the action depending on the permissions
- changes the available buttons in the Move/Copy dialog depending on the
permissions.
The same changes are done to the filelist view for bulk actions.
Signed-off-by: Roland Tapken <roland@bitarbeiter.net>
"FileList._updateDetailsView" expects either a file name (as a string)
or a file model (as an "OCA.File.FileInfoModel"), but when called
through "updateInList" an "OC.Files.FileInfo" object was given instead.
As the given attribute was not a model "_updateDetailsView" treated it
as a file name and tried to get the model for that file, which failed
and caused the details view to be emptied.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
All the tests in the "Renaming files" section added the test files,
although those calling "doRename()" added them by setting a path for the
file too. However, the path is ignored in the other tests, so adding the
files can be unified and moved to "beforeEach()".
This would be needed, for example, to show the details view for a file
before calling "doRename()".
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>