This was caused by the fact that the canPost property was not exposed from the ChatItem model.
I'm actually not sure why it didn't show an error trying to call a function that doesn't exist
Prior to this commit, we would only set the translation package for the
application's engine when `appSettings.locale !== "en"`.
This is problematic because it seems that `engine` is already provided with
a system default that may not be `en`. In practice, this means that, initially,
engine is loaded with, say `de`. `appSettings.locale` might be `en` but because
we're only loading the correct translation package when it's **not** `en`,
the application will stay in `de`.
Changing the language to `en` at runtime is fine, however once the application
is restarted, `engine` is again initialized with some other possible system default.
It seems that we should *always* load the translation packge when `appSettings` are
loaded.
When contract addresses that are not ERC-20 or ERC-721 were input, the token would be allowed to be added and would crash the app.
In addition, when an ERC-20 contract was deployed without a name and symbol, “Invalid ERC-20 address” would appear.
This PR adds error checking from the token detail lookup and reports the error back to the user in the modal. This prevents non-ERC-20/721 contracts from being able to be added to the app and prevents a crash.
Two fake messages are usually added to chat message lists inside a channel or
chat:
- One that imitates a chat identifier
- one that creates a button to fetch older messages
These two fake messages are added so it's ensured they show up at the beginning
of the chat.
The status timeline is also just a list of messages (filtered by a certain message
type), however there's no need to render these fake messages in this scenario.
That's why a `addFakeMessages` flag has been introduced which conditionally adds
those fake messages here: https://github.com/status-im/status-desktop/commit/3f012dbf0#diff-6aa545137319516beb03623bc6a9750e1d14a40c68d8868b5a672320fc4d680aR69
At some point, possibly around here (https://github.com/status-im/status-desktop/commit/8ee5abe57), the fake message for
the fetch more button has been reintroduced as default fake message.
This commit puts it back into the function so that it doesn't show up
inside the timeline view.
There was a UI bug in the StatusChatInput where, only in the timeline view,
the scrollview wrapping the textarea would have a weird behaviour in which
it would render the visible text(placeholder) *lower* than how it's actually
positioned. Once the textarea is clicked, it would re-adjust with a smooth
scroll.
Obviously this is undesired behaviour as the text should always render in the
correct position.
This commit finally fixes this weird behaviour by moving the dynamic height
calculation to the wrapping Rectangle and changing the textarea's top- and
bottom paddings dynamically.
Fixes#2018
refactor: move threadpool task declarations inline with views
Co-authored-by: Michael Bradley Jr. <michaelsbradleyjr@gmail.com>
Co-authored-by: Eric Mastro <eric.mastro@gmail.com>
Alright, this is an interesting one:
As described in #1829, when the profile popup is opened within the chat view,
users are still able to click *through* the popup on message, which then puts them in
an active state.
I've done a bunch of debugging as described [here](https://github.com/status-im/status-desktop/issues/1829#issuecomment-804748148) and after doing some
further debugging, I found out that `isMessageActive` isn't really the culprit here.
What causes this effect is the `HoverHandler` that's attached to the `CompactMessage` item.
`HoverHandler` is a standard QML type that emits `hoverChanged` signals so one can do things like
applying hover effects on elements, which is exactly what we do:
```
HoverHandler {
onHoverChanged: {
root.isHovered = hovered // `root` being the message item
}
}
```
I assume we went with this handler because putting a `MouseArea` in there instead, which fills
the entire message component pretty much eliminates all existing mouse handlers attached to
other child components, such as the profile image or the username of the message, which also
open a message context menu.
It turns out that, having a `HoverHandler` as described above, actually activates it when the
user clicks with the left mouse button as well (not just on hover). That's what causes the "click-through"
effect. This can be verified by setting `acceptedButtons` to `Qt.RightButton`, basically telling
the handler that only right clicks will activate it.
I then tried using `Qt.NoButtons` instead so that no button clicks and only hovers will activate
the handler, but that didn't seem to have any effect at all. It still defaults to `Qt.LeftButton`.
So the last resort was to disable the `HoverHandler` altogether, whenever either the profile popup,
or the message context menu (for emojis etc) is open.
Unfortunately, we don't have access to the profile popup in the compact message component, because it's
detached from the component tree. Therefore, I've introduced a new property `profilePopupOpened` on
the chat layout, which we can read from instead.
Fixes#1829
This commit introduces a `reset()` function so that search results inside
the application can be easily reset. It also introduces a `resultClickable`
flag which allows consumers of this component to decide whether a search result
is clickable and emits a dedicated event.
This is useful when UIs should only allow actions via the result icon button
(as it's the case with the new add-to-contact modal).
There was a bug introduced https://github.com/status-im/status-desktop/commit/2ac67f95a where we'd rely on the
possibly resolved public key, which is passed to `generateAlias()`.
The public key is never guaranteed to be an actual key (if resolution fails,
it's a an empty string). Passing an empty string to `generateAlias()` causes
`status-go` to crash and we don't handle that error.
This commit ensures that we only attempt to generate an alias when we
indeed have a successfully resolved public key.
