Some servers (e.g. InspIRCd v4) support the concept of a real username,
i.e. the username that was originally sent as distinct from their virtual
username set by services.
Closes: https://github.com/thelounge/thelounge/issues/4900
A user on IRC reported a bug where the topic would change to ":hello"
when the topic was modified to "hello" via the channel topic edit field.
The reason is that irc-framework also sanitizes /RAW commands
and hence our manually escaped trailing param gets another ":"
(which I'm not exactly sure it should be doing... /raw means raw
in my world, but oh well).
We do have a proper /topic command a user could be using, so the
fix is to just do that in the input box as well.
Dynamic imports won't work very well with modules and we don't
really need them, it's just there to save us an import statement.
Let's flip this to a static version.
The NetworkForm type is wrong, hence the compiler can't infer the type.
This needs quite some changes, so for now we just turn the linter off
for the 2 watch functions.
The whole component is too dynamic to fix easily.
The sort event bundled networks and channels for no reason at all.
They share none of the actual logic, so combining them just makes
the typing poor but serves no benefit.
The TS rewrite dropped the form that was expected to be passed
as props.
That lead to the password change being borked, as the fields
were always set to "null".
We don't need a form, can just use refs here.
https://github.com/thelounge/thelounge/pull/4649 broke existing
themes by removing the colored-nicks class from chat.
Considering that we don't bump the major version, keep backwards
compatibility for now
Currently, in `ChatInput.vue` we call `upload.abort()` which removes the event listeners, which are never added back. This effectively permanently disable uploads if the user navigates away to Settings or any other non-chat pages, and back.
Moves the binding to `mounted()` so that they're properly rebound when a chat window is in view, and also adds an `unmounted()` for clarity.
This should also fix an edge case if the page opens up on a non-chat page and there was never a ChatInput to unbind it, such as login page or add network pages.
Prior to this, the search is still racy but one tends to notice
this only when the DB is large or network is involved.
The user can initiate a search, get bored, navigate to another chan
issue a different search.
Now however, the results of the first search come back in and
hilarity ensues as we are now confused with the state.
To avoid this, keep track of the last search done and any result
that comes in that isn't equal to the active query is garbage and
can be dropped.
This means we also apply the collapsing to normal queries,
which might also collapse other things like joins / quits
which may be undesired by some
Fixes: https://github.com/thelounge/thelounge/issues/4583
The only thing that cares about user colors is the user component.
Putting a class value on the chat component seems to be the wrong
place.
This also allows us to remove various css selectors so that we
don't need to be that specific.
After all whatever has that class needs to be colored, we don't
care where it is.
Offset is eventually passed to sqlite as an OFFSET clause.
This works as follows:
sqlite> select num from seq limit 5 offset 0;
┌─────┐
│ num │
├─────┤
│ 1 │
│ 2 │
│ 3 │
│ 4 │
│ 5 │
└─────┘
sqlite> select num from seq limit 5 offset 5;
┌─────┐
│ num │
├─────┤
│ 6 │
│ 7 │
│ 8 │
│ 9 │
│ 10 │
└─────┘
However, the code currently emits a request for offset + 1, which ends
up skipping a message
sqlite> select num from seq limit 5 offset 5+1;
┌─────┐
│ num │
├─────┤
│ 7 │
│ 8 │
│ 9 │
│ 10 │
│ 11 │
└─────┘
Nachtalb put some infra in place that was never actually working.
It errors out when a user clicks on a message.
Remove the offending code, but keep it all in place so that we
can improve on it.
When we hit doSearch, we always reset the offset value to 0,
meaning we always hit the conditional (!0) and always set the
messageSearchInProgress flag to undefined.
This is wrong, we do want to set this flag when we initiate a search.
