Before, when the chat view was shown in the sidebar the sidebar height
grew to accomodate the full list of messages (or the chat view just
filled a section of the sidebar, depending on the browser). Instead of
that the chat view should grow to fill the available space in the tab
content, and the scroll bar should be provided by the list of messages
itself.
In order to do that it is necessary to modify the style of the tabs
content container to set "overflow: hidden". In Nextcloud 17 it was
possible to provide an additional set of CSS classes to be set in the
tabs content container when a tab was active with
"getTabsContainerExtraClasses", but unfortunately that is not currently
possible in Nextcloud 18. Therefore this needs to be done by explicitly
setting the desired CSS rules on the tabs content container when the
chat tab is the active tab (and removing it when it is no longer the
active tab).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the Talk sidebar is supported for a file a message is shown to the
user to explicitly join the conversation, and once joined the chat view
is shown in the chat tab. If a different file is selected the previous
conversation is left (even if the conversation for the new file is not
joined).
The sidebar tabs are created again whenever the sidebar is opened, be it
when changing to a different file or even when opening the sidebar again
for the same file after closing it. As the file of the current
conversation needs to be known to leave the conversation or not when the
FileInfo changes (so it is left if it is opened in a different file, but
kept if opened in the same file) the file ID of the current conversation
needs to be stored outside of the view.
Finally, as the AdvancedInput in shown in the chat view but there is no
route in use "this.$route.name" needs to be guarded.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The Talk sidebar is supported for a file when it meets certain sharing
conditions. If the Talk sidebar is not supported then a message is shown
to the user in the tab to share the file first.
In some cases it is not possible to know if the Talk sidebar is
supported or not only from the FileInfo data and it is necessary to
query the server. In those cases a loading icon is shown until the
response from the server is received.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This is just a temporary message; in the future the whole tab will be
hidden in that case, but it depends on a fix in server which was not
ready yet for beta 3.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The Message component expects that all messages have the "isReplyable"
property set. Although temporary messages are marked as not replyable as
soon as the message is received from the server the property will get
its real value.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
"overflow: scroll;" always* shows the scroll bars, even if they are not
needed; if the scroll bars should be shown only when needed "overflow:
auto;" should be used instead.
*In newer browsers "overflow: scroll;" behaves like "overflow: auto;",
so this change makes no difference in those cases, but older browsers
respect the expected behaviour.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Before, when the chat view was shown in the sidebar the sidebar height
grew to accomodate the full list of messages. Instead of that the chat
view should be limited to the available space in the tab content, and
the scroll bar should be provided by the list of messages itself.
In other tabs, like in the participants tab when there were a lot of
participants, something similar happened, and the conversation
information at the top of the sidebar as well as the tab headers were
scrolled when the participants were scrolled.
As the chat view tab has to provide its own scroll bars for consistency
now the scroll bars of all tabs are shown for their content instead of
for the whole sidebar. Note that if the tab provides some more specific
scroll bars (like done in the chat tab) those are the scroll bars shown
instead of the ones for the tab itself.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The signaling object is created after the signaling settings are
fetched. As the settings are fetched as soon as the application starts
it was assumed that the signaling object was always available when it
was going to be used, but that may not be the case if the request to
fetch the settings take longer than expected.
Now the signaling object is guarded behind an async function that
returns it if it is available or fetches the settings and then returns
the object once available. Also, if a new signaling object is tried to
be created while the settings are being fetched it will also wait until
the first request succeeded and return the same object in all cases.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>