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 div that contains the elements related to the creation of new files,
and thus the upload button, is always present in the DOM; it is hidden
or shown based on the folder permissions by adding or removing the
"hidden" CSS class. However, as the other CSS classes for the div are
"actions" and "creatable" and a "display: flex" rule was defined for
".actions.creatable" below the "display: none" rule for
".actions.hidden" the last one took precedence and the div ended being
always visible, even if the "hidden" CSS class was set. Now the rules
for the ".actions.hidden" selector are defined below the rules for the
".actions.creatable" selector and thus the "display: none" rule is
applied as expected.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Currently, the theming app assumes it's in the serverroot. However, with
Nextcloud's flexibility regarding configurable app paths, this is not a
safe assumption to make. If it happens to be an incorrect assumption,
the theming app fails to work.
Instead of relying on the serverroot, just use the path from the
AppManager and utilize relative paths for assets from there.
Fix#8462
Signed-off-by: Kyle Fazzari <kyrofa@ubuntu.com>
* adds a 107 error code together with the hint of the exception
* logs the exception as warning
* fixes#7946
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
Daniel Calviño Sánchez
Roeland Jago Douma
Morris Jobke
Nextcloud bot
John Molakvoæ (skjnldsv)
Julius Härtl
Kyle Fazzari
Arthur Schiwon
Marin Treselj
Robin Appelman
Roeland Jago Douma