Since the whisper cache entry was computed while holding the read-lock,
it was possible for a user in that cache to get deleted while the voice
thread drops the read lock in order to upgrade it to a write lock. In
such a case, the cache entry would contain an invalid (stale) user
pointer, which can lead to crashes when using the cache later on.
By moving the cache entry computation into the block in which we already
hold a read lock, we turn computing the cache and adding it to the cache
store into an atomic operation. As soon as the cache entry is in the
store, deleting a user is no longer an issue as that will implicitly
clear all whisper caches (thereby preventing stale cache entries).
The second call to pa_context_subscribe() was overriding the first, as a result we were only receiving sink events.
This caused hotplugging to fail with devices that don't have any output ports (e.g. USB microphones).
In 6c565689 the HostAddress was refactored. A check for isV6 when
creating a QHostAddress was removed. However, the QHostAddress
determines the (IPv4 vs IPv6) distinction at construction time.
This resulted in some regressions both visually and functional.
This commit reintroduces the distinction.
Fixes#6349
In the 'Messages' settings, when disabling a single notification method
for a single message type, all check-boxes will disappear in that
column if 'All messages' was checked to begin with. This is because the
automatic unchecking of the 'All messages' check-box is treated as
if the user actually clicked it. Using a QSignalBlocker before unchecking
the 'All messages' fixes the issue
Fixes#6302
In my previous PR (#6290) addressing this bug, I wrote:
> The issue seems to be caused by the scrollbar sometimes being in an
> inconsistent state immediately after a message is sent, but not any
> longer.
>
> My workaround is to add a call to QApplication::processEvents before
> setting the scrollbar to its maximum position to avoid the inconsistent
> state.
I have found that this change only reduces the likelihood of the
incorrect scroll behaviour from happening: it is still reproducible
after the log grows past a certain size.
In my testing since then, the cause of the "inconsistent state" described
previously seems to be the following: When images (whose contents are
stored in a base64-encoded data URL) are inserted into the log, they are
not loaded immediately. Instead, they are "fetched" (although no actual
network request occurs) by the `loadResource` implementation on
`LogDocument`. The "fetching" is triggered by the call to `setHtml` in
the `Log::validHtml` method. However, the code which sets the scroll bar
to stay at the bottom runs immediately (i.e. not asynchronously) in the
`Log::log` method. There also seems to be a hack that forces a re-layout
by sending a "font changed" event.
The intended behaviour appears to be that when a log entry is added the
log will scroll to the bottom if the entry is a message sent by the user
themselves, OR if the log was already scrolled to the bottom before
the entry was added.
The previous solution in place addressing the asynchronous image loading
was dispatching a `LogDocumentResourceAddedEvent` when the image is
loaded whose handler scrolls the log to the bottom, but this causes 2
problems:
First, the handler for this event always scrolls the log to the bottom
no matter what, which means messages containing images are handled
differently from the intended scrolling behaviour, i.e. messages
containing images ALWAYS cause the log to scroll to the bottom instead
of obeying the rules described above.
Second, it seemingly causes the issue described in #2504. It looks like
there's a race condition when the scroll position is set from the main
thread as well as in an event handler. I couldn't get to the bottom of
the exact source of the issue because there is so much deferred
execution going on, but I am confident that adding resources/forcing
re-layout events from an event handler is to blame.
My current solution is to remove as much of this asynchronous code as
possible. The use of a `QNetworkReply` seems to be leftover from when
Mumble supported remote images in chat. As described above, this
implementation was problematic and its complexity is no longer needed,
so I changed the implementation of `LogDocument::loadResource` to simply
check that the image URL is valid and has the `data://` scheme and then
just fall back to QTextDocument::loadResource`.
Implementing the solution this way eliminates the need for
`LogDocumentResourceAddedEvent` because everything happens in order as
expected and there is no need to "correct" the scroll value after the
image gets loaded. I therefore removed this class and the associated
code.
The default behaviour of `QTextEdit` is that it scrolls to the bottom
whenever contents are added. `LogTextBrowser::scrollLogToBottom` seems
to be a workaround to try to get the log to stay at the bottom despite
the scroll bar jumping issue. With my solution, this method can be
removed, and we only need to worry about "restoring" the previous scroll
value when a message from another user arrives and the log isn't already
scrolled to the bottom.
Currently translated at 100.0% (2156 of 2156 strings)
TRANSLATION: Update Chinese (Simplified) translation
Currently translated at 100.0% (2156 of 2156 strings)
TRANSLATION: Update Chinese (Simplified) translation
Currently translated at 100.0% (2150 of 2150 strings)
TRANSLATION: Update Chinese (Simplified) translation
Currently translated at 100.0% (2150 of 2150 strings)
Co-authored-by: Eric <zxmegaxqug@hldrive.com>
Co-authored-by: Hosted Weblate <hosted@weblate.org>
Co-authored-by: deluxghost <deluxghost@gmail.com>
Translate-URL: https://hosted.weblate.org/projects/mumble/mumble-client/zh_Hans/
Translation: Mumble/Mumble Client
Currently translated at 100.0% (2156 of 2156 strings)
TRANSLATION: Update Swedish translation
Currently translated at 100.0% (2150 of 2150 strings)
Co-authored-by: Hosted Weblate <hosted@weblate.org>
Co-authored-by: bittin1ddc447d824349b2 <bittin@reimu.nl>
Translate-URL: https://hosted.weblate.org/projects/mumble/mumble-client/sv/
Translation: Mumble/Mumble Client
Currently translated at 100.0% (2156 of 2156 strings)
Co-authored-by: Hosted Weblate <hosted@weblate.org>
Co-authored-by: John Doe <thraex@numericable.fr>
Translate-URL: https://hosted.weblate.org/projects/mumble/mumble-client/fr/
Translation: Mumble/Mumble Client
Currently translated at 100.0% (2156 of 2156 strings)
TRANSLATION: Update Spanish translation
Currently translated at 100.0% (2153 of 2153 strings)
TRANSLATION: Update Spanish translation
Currently translated at 99.1% (2135 of 2153 strings)
Co-authored-by: Hosted Weblate <hosted@weblate.org>
Co-authored-by: gallegonovato <fran-carro@hotmail.es>
Translate-URL: https://hosted.weblate.org/projects/mumble/mumble-client/es/
Translation: Mumble/Mumble Client
Currently translated at 100.0% (2156 of 2156 strings)
TRANSLATION: Update Polish translation
Currently translated at 100.0% (2153 of 2153 strings)
TRANSLATION: Update Polish translation
Currently translated at 100.0% (2150 of 2150 strings)
Co-authored-by: Hosted Weblate <hosted@weblate.org>
Co-authored-by: Matthaiks <kitynska@gmail.com>
Translate-URL: https://hosted.weblate.org/projects/mumble/mumble-client/pl/
Translation: Mumble/Mumble Client
Currently translated at 99.7% (2150 of 2156 strings)
TRANSLATION: Update German translation
Currently translated at 98.2% (2118 of 2156 strings)
TRANSLATION: Update German translation
Currently translated at 98.1% (2117 of 2156 strings)
TRANSLATION: Update German translation
Currently translated at 98.3% (2115 of 2150 strings)
TRANSLATION: Update German translation
Currently translated at 100.0% (2110 of 2110 strings)
Co-authored-by: David <dawin@users.noreply.hosted.weblate.org>
Co-authored-by: Ettore Atalan <atalanttore@googlemail.com>
Co-authored-by: Hosted Weblate <hosted@weblate.org>
Co-authored-by: Robert Adam <dev@robert-adam.de>
Translate-URL: https://hosted.weblate.org/projects/mumble/mumble-client/de/
Translation: Mumble/Mumble Client
Currently translated at 100.0% (2156 of 2156 strings)
Co-authored-by: Hosted Weblate <hosted@weblate.org>
Co-authored-by: John Doe <thraex@numericable.fr>
Translate-URL: https://hosted.weblate.org/projects/mumble/mumble-client/tr/
Translation: Mumble/Mumble Client
In 635d71960f cache invalidation for access tokens was added.
A check for ``uSource->iId >= 0`` was added which was intended
to only parse access tokens, if the ``authenticate`` method was
not returning an error code.
As it turns out though, ``uSource->iId`` will be -1 for unREGISTERED
users instead of unAUTHENTICATED users which lead to a bug
where unregistered users would not have the correct channel access
when connecting to the server. A subsequent update of their tokens
would fix that.
This commit moves the respective code block down and changes the
condition to ``ok``, which should now behave as originally intended.
Fixes#6334
The function was called "toggle*" and yet it didn't toggle anything but instead only acted as a setter for the respective property. Therefore, the naming has been adjusted accordingly.
The function was called "toggle*" and yet it didn't toggle anything but
instead only acted as a setter for the respective property. Therefore,
the naming has been adjusted accordingly.
QT invoke functions use the size_t type from std:: and some of the API functions that calls these invoke functions using the size_t type from the global namespace.This commit fixes the size_t type as std::size_t for these QT invoke functions.
To make the build reproducible, it's needed to set the timezone as
otherwise the date could vary based on the timezone of the build server.
Link: https://bugs.debian.org/1060254
QT invoke functions use the size_t type from std:: and some of the API
functions that calls these invoke functions using the size_t type from
the global namespace.This commit fixes the size_t type as std::size_t
for these QT invoke functions.
Co-Authored-By: Abdullah Ömer Yamaç <aomeryamac@gmail.com>
This commit refactors the code repeated in the main.cpp file.
Three connect functions were called with same parameters.
Co-Authored-by: Abdullah Ömer Yamaç aomeryamac@gmail.com
In b5a67c05f a buffer in the PulseAudio backend was made static, but
at the same time the memset(0) was removed.
In combination, that lead to a bug where the last few frames
of any given audio played back was repeated until something
else filled the buffer.
This commit adds a simple fill to the buffer where the memset(0)
previously was fixing the bug.
When selecting new public servers, we randomize their order. The random number used for that is an unsigned integer from which we compute the modulus with the list size in order to get a random index into the list.
This involved an implicit conversion from an unsigned integer (the random number) to a signed integer (the list index - as Qt uses signed integers for that). Thus, b5a67c0 added an explicit cast to a signed integer. However, it did this to the random number before the modulus operation, meaning that if a large enough random number is drawn, the cast would actually create a negative integer, yielding a negative list index after the modulus. This caused a crash of the application.
The fix consists in switching to using the bounded() function that has an overload for signed integers and which can directly generate numbers in the desired range, making all of the above superfluous.
Fixes#6306
When selecting new public servers, we randomize their order. The random
number used for that is an unsigned integer from which we compute the
modulus with the list size in order to get a random index into the list.
This involved an implicit conversion from an unsigned integer (the
random number) to a signed integer (the list index - as Qt uses signed
integers for that). Thus, b5a67c05fb added
an explicit cast to a signed integer. However, it did this to the random
number before the modulus operation, meaning that if a large enough
random number is drawn, the cast would actually create a negative
integer, yielding a negative list index after the modulus. This caused a
crash of the application.
The fix consists in switching to using the bounded() function that has
an overload for signed integers and which can directly generate numbers
in the desired range, making all of the above superfluous.
Fixes#6306
Co-authored-by: Thomas Lange <thomas-lange2@gmx.de>
Instead of relying on explicitly having to use the "Release" target, we
now enable LTO for everything but the special "Debug" target. That is,
we assume that every configuration other than "Debug" is likely meant as
some sort of release build (potentially with external flags) and thus
we want to make use of LTO.
In various places we relied on compiler extensions such as
variable-length arrays on the stack or using non-standard escape
sequences. In order to make our code as portable as possible, these
parts of the code have been refactored to only use standard C++.
Furthermore, the new warning settings triggered a bunch of new warnings
all over the place that have been addressed by this commit.
The migration path was implemented in
0e17c5394c but the QUuid object created
for the GKey keyboard shortcuts had an error in the constructor
arguments (wrong pairing of bytes) which would lead to some bytes being
discarded and thus to a different (invalid) QUuid.
This has been fixed.
The way this union was accessed is not covered by the C++ standard and
was therefore undefined behavior. Therefore, the code was rewritten to
stick to standard C++.
