The signaling backend was not notified when the password, type or read
only state of the room was modified so, in turn, the signaling backend
did not notify the clients about those changes.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
As a new Clipboard object needs to be created again when its
corresponding button is rerendered the previous object is now explicitly
destroyed to ensure proper lifecycle management.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the Clipboard object is created it attaches event listeners to the
given element or to all the elements that match the given DOM selector.
As all the clipboard buttons in the Talk UI (except the one in the empty
content view) have the "clipboard-button" CSS class all the Clipboard
objects listened to clicks on all the buttons, so clicking on a single
button triggered as many copies as buttons and thus Clipboard objects
were in the page. Now the Clipboard objects attach listeners only to
their corresponding clipboard button.
Note that it is not possible to use just one Clipboard object attached
to all the clipboard buttons, though, as the attached elements are fixed
when the Clipboard object is created and thus clipboard buttons added
after that are not taken into account. Therefore it is much easier to
keep track of a single button and create again its Clipboard object when
it is rerendered.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This fixes the code so it behaves as stated in the documentation.
In practice currently this should make no difference, as in the Files
app the user joins the room immediately after getting its token;
however, this makes possible to get the token without joining the room,
which will be needed in the future to improve the UX of the Files app.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The integration tests check that a user can join a file room again after
leaving it, but the user is removed from the room when leaving it due to
how the tests are written; in "the real world" leaving the room does not
remove the user.
The reason is that in the tests the room token is got by one user but
the room is joined by a different user. Currently the user is added to
the room as a permanent participant when getting the token instead of
when joining the room, so in the tests the user that joins the room is a
self-joined user that is removed once she leaves the room; in "the real
world" the user would have needed to get the token of the file room,
which would add her to the room and thus she would not be removed after
leaving, only after explicitly removing herself.
Due to all this the tests were changed to test joining the file room
again after the user removes herself instead of after she leaves the
room.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The setter methods in EditableTextLabel (indirectly) update its HTML
elements using "getUI()". Those setters may be used before the label is
first rendered (for example, to set up some default values in the
initialization of a parent view), so "bindUIElements()" needs to be
called to prevent "getUI()" from failing due to "this._ui" not being
defined yet in those cases (note that no UI elements will be actually
bound, as before the first render they have not been created yet, but
that is not a problem due to the way in which the elements are updated
from the setters).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Nextcloud bot
Daniel Calviño Sánchez
Joas Schilling
dependabot-preview[bot]
Roeland Jago Douma
Marco Ambrosini