In some circumstances (for example, if the signaling server provides an
incorrect list of users) the peer that received the offer can disconnect
from the peer that created the offer without causing the peer that
created the offer to disconnect from the peer that received the offer
too.
A peer only tried to connect with another peer if its session ID was
larger than the session ID of the other peer; otherwise it just waited
for the other peer to start the connection instead. This is done that
way to prevent overloading a peer joining a room.
However, in the scenario above, the peer that received the offer just
waited for the peer that created the offer to start the connection
again. As the peer that created the offer was not aware of the
disconnection it did not try to connect again, and thus they never
reconnected.
It is not possible to ensure that the peer that created the offer will
always disconnect from the peer that received the offer if the peer that
received the offer disconnects from the peer that created the offer, so
this is handled instead by making that peers with smaller session IDs
also start a connection if the peer with the larger session ID did not
in a reasonable time.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
In some circumstances (for example, if the signaling server provides an
incorrect list of users) the peer that created the offer can disconnect
from the peer that received the offer without causing the peer that
received the offer to remove the peer that created the offer.
In that situation, if the peer that created the offer then tried to
connect again with the other peer the other peer created a new "Peer"
object that was used instead of the old one. However, as the old one was
not removed, its video element (which was no longer updated) was kept
visible, hiding the video element linked to the new "Peer" object and
making it look frozen.
It is not possible to ensure that the peer that received the offer will
always remove the peer that created the offer if the peer that created
the offer disconnects from the peer that received the offer, so this is
handled instead by removing the stale "Peer" objects when new offers are
received.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When a user requests the signaling messages from the internal signaling
server first the last ping of the user is updated. Then, after waiting
for at most 30 seconds, the list of users active in the room is
returned.
That list was based on the users whose last ping happened around 30
seconds ago or less (it could be a bit longer than 30 seconds, but the
described problem remains in that case too); if other user pulled the
messages slightly before the current user and that other user did not
pull the messages again (or the chat messages, as that updates the last
ping too) before the user list was returned that other user was not
included in the list, as her last ping happened more than 30 seconds
ago.
Now the elapsed time since the last ping for users returned in the list
is longer than the timeout used for pulling messages (and chat messages)
to ensure (up to a point) that active users will be included in the list
even if it took a bit longer for them to pull messages again.
The drawback of this approach is that the internal signaling server will
now need a few more seconds to notice when a user left a call abruptly,
but before it was not immediate anyway and it should not be a common
scenario either.
Finally, note that it is unlikely that more than 40 seconds pass between
the ping is updated for the current user and the user list is returned,
but the condition to handle that case gracefully was kept to be on the
safe side.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When a user requests the signaling messages from the internal signaling
server first the last ping of the user is updated. Then, after waiting
for at most 30 seconds, the list of users active in the room is
returned.
That list was based on the users whose last ping was more recent than 30
seconds ago, so when there were no other messages and the waiting timed
out the last ping of the current user set when the request started
happened 30 seconds ago or more, and thus the current user was not
included in the returned list (unless her ping was updated to a more
recent value by a different request, like polling for chat messages).
Now the users returned in the list are those whose last ping is more
recent than or equal to 30 seconds, or more recent than or equal to the
signaling ping of the current user if it is larger than 30 seconds.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
"guest.css" overrides the default style of inputs set in "input.scss",
which causes all inputs in the public share auth page to look like the
main password input. Due to this, the rules from "input.scss" need to be
restored for inputs in the Talk sidebar to get the proper appearance.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
"guest.css" sets ".button" elements to inline-block display, but the
edit button, which is a "span", is expected to be displayed as inline to
get the proper size.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the editable text label for room names was fixed the rules were
added for all editable text labels, which broke the editable text label
for guest names. Those rules are now applied only to room names, which
implicitly fixes guest names.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
To check that the chat view is shown in the main view the ancestor
locator of the chat view must be the main view; if the chat ancestor set
in other steps is used it just checks that the chat view is shown
somewhere, but it does not guarantee that it is shown in the main view.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Joas Schilling
Nextcloud bot
Joas Schilling
Daniel Calviño Sánchez
Ivan Sein
Anton Stuetz