When no timeout was given "show()" used the default timeout of
"OCP.Toast", which is 7 seconds instead of indefinitely as stated in the
documentation of "show()". "showHtml()" should also indefinitely show
the notification if no timeout is given, but due to the strict
comparison the notification was indefinitely shown only when a timeout
of 0 was explicitly given. Now both methods show the notification
indefinitely (or until it is explicitly hidden) when no timeout is
given.
The unit tests did not catch this error because "showHtml()" had no
tests (as before the move to Toastify it was called from "show()" and
thus implicitly tested), and because "show()" verified that "hide()" was
not called after some time; "hide()" is no longer called from "show()"
since "OCP.Toast" is used internally, so the test always passed even if
the notification was indeed hidden. Now the test is based on whether the
element is found or not, and explicit tests were added too for
"showHtml()".
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
"showTemporary()" when a timeout was given was being tested along with
the "show()" tests; now there are two separate tests when a timeout is
given, one for "showTemporary()" and one for "show()".
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Tje jQuery object created through "$('#testArea .toastify')" will be
always defined even if no elements were found, so the check does not
really work; instead, it should be checked the number of elements found.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This fixes HTML messages in "OC.Notification.showTemporary" (as
"showHtml" was not set based on "isHTML"), and also makes OCP.Toast to
keep the old OC.Notification API when used directly.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
humanFileSize: add test with locale
humanFileSize: use canonical locale
humanFileSize: skip test w/o toLocaleString support
humanFileSize: stub getCanonicalLocale
OC.getCanonicalLocale: cover undefined case
humanFileSize: fix getCanonicalLocale stub
Signed-off-by: Claas Augner <git@caugner.de>
When a Snap was disabled it stopped listening to the events, but if a
drag gesture was being performed it was kept as active. Thus, when the
Snap was enabled again move events were handled as if the Snap had never
been disabled, causing the gesture handling to continue where it was
left.
When the Snap for the navigation bar is disabled by an app it could be
as a result of a different gesture being recognized by the app (for
example, a vertical swipe) once both gestures have started. In that case
when the other gesture ends and the Snap is enabled again any pointer
movement will cause the navigation bar to slide until an "up" event is
triggered again (obviously not the desired behaviour).
Due to all this now when the Snap for the navigation bar is disabled by
an app the current drag gesture for the navigation bar is ended.
Note that this was added as a parameter to "Snap.disable()" instead of
done unconditionally to keep back-compatibility with the previous
behaviour (probably not really needed as it is unlikely that any app is
using the Snap library relying on that behaviour... but just in case).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
On narrow screens a slide gesture can be used to open or close the
navigation bar. However that gesture could conflict at times with the
gestures used by certain apps (for example, if the right sidebar is open
the user may expect to close it by dragging it to the right, but that
could open the navigation bar instead depending on how the events are
handled). This commit makes possible for apps to disallow and allow
again that slide gesture.
In any case, note that applications can only disallow the gesture,
but they can not enable it. That is, they can prevent the gesture from
being used on narrow screens, but they can not make the gesture work on
wide screens; they are always limited by the base rules set by the core.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The slide gesture is enabled or disabled depending on the width of the
browser window. In order to easily control that width the karma-viewport
plugin is now used in the unit tests.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
this fixes#3634
1. fixed computerFileSize to be more picky about incorrect values
2. more tests for computerFileSize
3. use computerFileSize to validate user quota
Signed-off-by: Artur Neumann <info@individual-it.net>
This function is often used in a wrong and potential dangerous way... Thus we should escape the URL per default and offer developers to disable the automatic escaping via an option parameter if they really want that behaviour.
Might break some things, however, those things are then easy to fix and we really have a ton of bugs caused by this...
Fixes https://github.com/owncloud/core/issues/14228
