When using Firefox, the participants tab view requires its overflow to
be hidden to limit its size to the size of its parents. Otherwise, the
participants tab view grows to fit its children; if that happens then no
scroll bar is shown for the participants list, as the participants list
is tall enough to fit all its items (even if they are not visible
because they are in the overflow area). In Chromium, on the other hand,
the participants tab view size is always limited by its parents, no
matter if the overflow is hidden or not.
In a similar way, once the overflow is hidden the bottom padding added
to the participants list has to be added to its last item instead.
Firefox only takes into account the bottom padding in the participants
list when the list has not overflown the participants tab view; it needs
to be added to the last item to be taken into account also when the
participants list is taller than the participants tab view. Chromium, on
the other hand, always takes into account the padding, no matter if it
is added to the participants list or to its last item.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The chat between two users was tested by a sequence of one user sending
a message and immediately after that the other user sending another
message. Most of the time the messages were processed in the server in
the order in which they were sent, but sometimes it could happen that a
previous message took longer than usual to get to the server and then
the next message from the other user was processed before it; in those
cases the test failed due to the messages not matching the expected
order. Now each user waits for the last message of the other user to be
received before sending the next message.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the chat view is shown in the main view the call UI (videos and
screens) is hidden using a CSS trick. However, when there is no chat
view in the main view the elements for videos and screens were always
visible. Those elements are initially "empty", but once the user joins a
call they are filled with contents (like the icon to mute the own audio,
or the avatar of the speaking user). As the elements were always visible
the call UI was shown in the main view after a room was left (either
explicitly or implicitly, for example, if the moderator deleted the
room), as in those cases there is no chat view hidding them.
Besides that, the empty content element was hidden when joining a call
but never shown back again. Due to that when a room was left after
joining a call the empty content element was also missing.
Now the videos, screens and empty content are explicitly shown or hidden
as needed when the user joins a call, leaves a call, or leaves a room,
just like it is done with the chat view.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
In order to check if certain conversation is the active conversation
the element for the active conversation list item with the given name
was found and then it was verified that it was visible; waiting for the
element to be visible using the implicit wait made to find the element
is a valid approach if the element is always visible when it exists in
the DOM. However, during the lapse between removing/deleting the
conversation and getting the updated conversation list from the server
the element may be hidden but exist in the DOM. Due to that it has to be
explicitly waited for the element to be visible.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Depending on timings it could happen that the guest name was set before
the room token was known (resulting in `null` in the url) or before the
user has joined the room (so setting the name got rejected).
Signed-off-by: Joachim Bauch <bauch@struktur.de>
This avoids a conflict (introduced by #864) with the existing ´usersChanged`
event which is triggered when the `inCall` status of a user has changed.
Signed-off-by: Joachim Bauch <bauch@struktur.de>
When explicitly leaving the current room through the room list view the
chat view was detached. However, as the internal state of the
Application object (which manages the placement of the chat view) was
not updated the chat view was always hidden from that point on until the
page was reloaded.
Moreover, as the chat view was detached only when explicitly leaving the
current room the chat view was not hidden for other users in the room if
it was deleted by a moderator.
As the "leaveCurrentRoom" event is triggered in the room channel when
the current room is left, either explicitly or implicitly, now the
Application object listens to that event and hides the chat view as
needed when it is received.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Ivan Sein
Nextcloud bot
Daniel Calviño Sánchez
Julius Härtl
Joas Schilling
Joas Schilling
Joachim Bauch
Joachim Bauch