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.
Move the remaining stickers spawnAndSend (obtainAvailableStickerPacks) into a threadpool task.
refactor: create a base class for tasks models to inherit from
NOTE: this branch is based off of `experiment/tasks-3` and should be rebased on master once that branch is merged.
The `TaskManager` threadpool is a memory-safe replacement for the `spawnAndSend` operations that are currently causing memory issues in status-desktop.
From a fundamental memory management point of view, `libstatus/settings`, `libstatus/contracts`, and `libstatus/tokens` (custom tokens) have all been converted to `{.threadvar.}`s and `Atomic[bool]`s to maintain the cache and `dirty` flag across threads, respectively, eliminating the need for thread locks and incorrect `{.gcsafe.}` compiler overrides.
The successful [recyclable threadpool experiment from `nim-task-runner`](https://github.com/status-im/nim-task-runner/blob/test/use-cases/test/use_cases/test_sync.nim) using `AsyncChannel[ThreadSafeString]`s was brought over to `status-desktop` and implemented in somewhat of a hardcoded manner, as we knew this would save some time instead of trying to create a fully fleshed out `nim-task-runner` API and build a miraculous macro that may or may not be able to generate the needed API.
The threadpool is started by the `TaskManager` and both the `TaskManager` and the `TaskManager`'s threadpool are started as early as possible in the application lifecycle (in `nim_status_client.nim`). The `TaskManager` creates a thread to run the threadpool. During its initialization, the threadpool then spools up all the threads it will manage and puts them in an idle thread sequence. This is to prevent expensive thread creation and teardown happening during the app's lifetime as it is quite expensive and blocks the main thread. When tasks comes in to the pool, the task is sent to an idle thread, or put in a queue if all threads are busy. The idle thread is moved to the busy thread sequence. When a task is completed, the thread is taken out of the busy threads sequence and moved back in to the sequence of idle threads, effectively recycling it.
The first `spawnAndSend` we were able to change over to the new threadpool was `estimate`, which estimates the gas of a sticker purchase transaction.
From the consumer point of view, the existing `spawnAndSend` to achieve this looks like:
```nim
proc estimate*(self: StickersView, packId: int, address: string, price: string, uuid: string) {.slot.} =
let status_stickers = self.status.stickers
spawnAndSend(self, "setGasEstimate") do:
var success: bool
var estimate = status_stickers.estimateGas(packId, address, price, success)
if not success:
estimate = 325000
let result: tuple[estimate: int, uuid: string] = (estimate, uuid)
Json.encode(result)
```
And the new syntax looks like this:
```nim
proc estimate*(self: StickersView, packId: int, address: string, price: string, uuid: string) {.slot.} =
self.status.taskManager.threadPool.stickers.stickerPackPurchaseGasEstimate(cast[pointer](self.vptr), "setGasEstimate", packId, address, price, uuid)
```
The logic inside the `spawnAndSend` body was moved to [src/status/tasks/stickers.nim](https://github.com/status-im/status-desktop/compare/experiment/tasks-3?expand=1#diff-09e57eef00b0cee5c4abdb9039f948d8372e7003e09e934a9b4c7e9167d47658).
This is just the first migration of `spawnAndSend`, however moving the majority of the remaining `spawnAndSend`s will likely just be an exercise in copy/pasta. There will be one or two that may require a bit more thinking, depending how they rely on data from the model.
Once the `spawnAndSend`s have been converted to the threadpool, we can start implementing the [long-running process from the task runner use case experiments](https://github.com/status-im/nim-task-runner/blob/test/use-cases/test/use_cases/test_long_running.nim).
And finally, we can then implement the [async tasks](https://github.com/status-im/nim-task-runner/blob/test/use-cases/test/use_cases/test_async.nim) if needed.
@michaelsbradleyjr and I spent many hours digging in to the depths of nim's memory management in an attempt to understand it. We have created [a presentation with our task runner experiment findings](https://docs.google.com/presentation/d/1ItCxAfsVTcIoH_E4bgvmHljhbU-tC3T6K2A6ahwAedk/edit?usp=sharing), and @michaelsbradleyjr has spent time [answering questions off the back of that presentation.](https://gist.github.com/michaelsbradleyjr/1eaa9937b3fbb4ffff3fb814f0dd82a9).
We have created a fork of `edn.nim` at `status-im/edn.nim` and we need the PR to be merged and the commit hash updated before we can merge this PR in to `status-desktop`.
We've introduced a regression in https://github.com/status-im/status-desktop/commit/f1e83f74b#diff-f35edd413addd14c1f81816d6b5ee2bcbdf85fa0e3295d324cb78c98e26d4327L364 where we check whether an RPC's `error` is `null`
and its `result` is not `null`.
This breaks the application with an illegal storage access,
as in case of a successful API call, the response will have only a `result` key
(even when it's `null`).
Since we haven't done anything with a possible `error` in the reponse even before
that change was made, this commit removes the `error` check and safe guards around
whether `result` exists.
Fixes#2062
Allow up to 5 images to be dragged and dropped in to one-on-one chats and in the timeline. Can be combined with the existing upload button. The upload file dialog has been changed to allow multiple selections. Drag and dropped images adhere to the following rules, with corresponding validations messages:
- Max 5 image
- Image size must be 0.5 MB or less
- File extension must be one of [".png", ".jpg", ".jpeg", ".heif", "tif", ".tiff"]
Drag and drop and uploaded images are now also deduplicated.
Prior to this commit, communities without an image would render invisible
in the navigation bar of the application. To avoid this, we're now falling
back to our StatusLetterIdenticon component, which renders the first letter
of the community name with the color of the community.
In https://github.com/status-im/status-desktop/commit/31a9d1a6f we've fixed
a bug where a contact's thumbnail hasn't been passed to the `saveContact`
API.
Unfortunately, that fix wasn't memory safe. There are cases when a contact's
`identityImage` is `nil`, resulting in illegal storage access when accessing
a contact's thumbnail.
This commit fixes the issue by safe guarding around `identityImage` possibly
being `nil`.
Turns out message reactions weren't functional in 1 on 1 chats.
Reaction signals come with a `chatId` that they correspond to, which is
then used to determine to channel and message list to apply/remove
the reaction to.
Inside of a 1 on 1 chat, the `chatId` of a reaction coming from the
will always be the pubKey of the the user that receives it.
A user however, usually doesn't store a chat item for her own pubKey
unless it's of type `Profile`.
This results in an illega storage access as reported in #1828
This commit fixes this bug by checking whether the reaction `chatId`
matches the user's `pubKey`. If that's the case, we know that the reaction
corresponds to the reaction's `fromAuthor` chat.
Fixes#1828
This commit introduces the new design and behaviour of the modal
that opens up when starting a new 1-on-1 chat.
Main changes include:
- New search UI/UX functionality of users and ENS resolutions
- Composed view of existing contacts and contacts to be searched
- Ability to add contacts from within the modal
Closes: #1747
This commit does a bunch of things:
- First and foremost, it removes the active channel dependency.
This is needed to have it operate on the correct channel object,
without forcing us to change the active channel (e.g. right-clicking
on a channel item that's not active, will make it active eventually)
- To make that work, this commit changes the `ChannelContextMenu`
to receive a `ChatItemView`, so it can be used for things like determining
what menu options are shown, what members are in a group, whether
someone is admin of a group etc.
- This also required a new `QtProperty` called `contextChannel`.
The reason this is required, is because in some cases, like receiving
members count of groups, we need a complete `ChatItemView` object
as we don't have access to certain APIs otherwise.
- Unfortunately, we can't pass down `activeChannel` every where for that
because sometimes the context menu should not actually operate on
the active channel.
Fixes: #1755
fixes#935
A bug occurs when someone requests a large amount of funds from you since the gas estimation will fail and there isn't a way of handling errors in the source yet.
This PR handles the error appropriatley for both `estimateGas` and `estimateTokenGas` where the response is only converted from hex to int if the RPC call was successful. Otherwise return the error message as the response and let the UI decide how to display it.
Currently the error for gas estimation in transaction bubbles is displayed in a popup however, ive come to realize that 2 popups open instead of one. This is a new bug of which I can't pinpoint the root cause at the moment and have opted to file a separate issue for it.
As reported in #1584 the message that asks users to backup their seed phrase
is shown even when the seed phrase was imported in the first place, implying that
the mnemonic is already backed (it has to come from somewhere, right?).
This commit introduces a new `appSettings` property that is temporarily set to
determine whether or not the backup message should be shown.
It's set only temporarily because we actualy determine whether we want to show the
backup message, by checking if the account's mnemonic is still stored in the settings.
When a backup is done, Status removes the mnemonic from the profile settings.
So in order to get the right behaviour we need to make sure to remove the mnemonic
from the profile settings after the account has logged-in and originated from
an imported seed phrase. This is done by setting the mentioned property.
Closes#1584
This commit makes reactions in the status timeline work.
There are two things prior to this commit that are broken:
1. The logic that opens the reaction context menu always expects
and instance of `chatsView` because it tries to calculate a users
nickname. Such an instance isn't always available in that context, so
the nickname logic has been moved to `appMain` for now, removing that
dependency and therefore making it work in both, the chat view as well
as the status view.
2. While 1) makes the context menu work, it turns out that adding and
removing reactions inside the status timeline is still not working.
The reason for that is, that the reactions component maintains its own
`messageList`, which isn't aware of the fact that reactions for messages
coming from chats of `ChatType.Profile`, need to go into a dedicated
message list for `ChatType.Timeline`.
In other words, reactions are sent and removed from message in messagelists
that don't actually exist.
This commit fixes both of these things by ensuring the message lists
maintained by reactions are timeline aware. Also ensuring updates are
done correctly.
The `messageList` model used for rendering messages gets notified by the
`activeChannelChanged()` signal. That signal is not immediately emitted inside
the timeline when new messages are received.
This causes the underlying view data to be out of sync with the model,
causing UI bugs, such as rendering the `EmptyTimeline` component when in fact,
the timeline is not empty.
To fix this, there are two options:
1. Change the signal from `activeChannelChanged` to `messagePushed` signal, which
is for sure emitted when messages are received
2. Ensure `activeChannelChanged` is emitted when messages are pushed and the
active channel is indeed the timeline
Since the application has been relying on `activeChannelChanged` so far, I decided
to go with option 2 as I'm not sure whether option 1 would introduce other unwanted
side effects.
When the network connection is changed, the sticker packs are cleared and then re-loaded (either loading the offline (installed) sticker packs, or all the sticker packs from the network).
Stickers can be sent while offline, though the sticker images do not load once offline (this is likely a side effect of the bug described below).
There is a known bug in QNetworkAccessManager (https://bugreports.qt.io/browse/QTBUG-55180) that was re-introduced in 5.14.1 that does not allow us to download resources if we go offline then come back online. The workaround employed in this PR manually sets the NetworkAccessible property of QNetworkAccessManager once we have been connected back online. The NetworkAccessible property is marked as obsolete and will be removed in Qt6, so it is something that we need to be aware of when we upgrade. However the hope is that the bug has been fixed.
Close StickersPopup when disconnected from network (so that re-loading of sticker packs doesn't look out of place).
fix: set network status correctly at load
feat: stickers gas estimate async
feat: When network re-connected, any http images that were not properly loaded in an ImageLoader component will automatically be reloaded.
fix: Sticker button loading icon
chore: Bump nimqml and dotherside
NOTE: This PR uses an updated nimqml and dotherside. The respective changes should be merged first, and the commit hash should be bumped in this PR prior to merging. Relevant PRs:
[https://github.com/status-im/dotherside/pull/20](https://github.com/status-im/dotherside/pull/20)
[https://github.com/status-im/nimqml/pull/17](https://github.com/status-im/nimqml/pull/17)
When sending a profile status update, the message has to be sent to
a specific channel that has the id `@PUBKEY`.
This commit introduces a flag that controls whether the message is
sent to the currently active channel, or tot he profile status channel.
The same is done for the `sendImage` API.
Fixes#1377.
Fixes#1479.
Two sites have been added to the whitelist: giphy.com and tenor.com.
`imageUrls` in its entirety has been removed and instead all links are being handle through the message `linkUrls`. This prevents double-handling of urls that may or may not be images.
The logic to automatically show links previews works like this:
1. If the setting "display chat images" is enabled, all links that *contain* ".png", ".jpg", ".jpeg", ".svg", ".gif" will be automatically shown. If the URL doesn't contain the extension, we are not downloading it. This was meant to be somewhat of a security compromise as we do not want to download each and every link posted in a message just to find out its true content type.
2. If the above setting is *disabled*, then we follow the whitelist settings for tenor and giphy. This allows us to preview gifs that do not have a file extension in their url.
feat: bump status-go to the commit that supports the new whitelist (https://github.com/status-im/status-go/pull/2094), and also lets us get link preview data from urls in the whitelist. NOTE: this commit was branched off status-go `develop`, so once it is merged, and we update this PR to the new commit, we will effectively be getting status-go develop changes. We *could* base that status-go PR off of master if it makes things easier.
fix: height on settings update issue
feat: move date/time of message below links
fix: layout issues when changing setting `neverAskAboutUnfurlingAgain`
feat: Add MessageBorder component to aid in showing rounded corners with different radius
Previously, this API would take a flag `oneToOne` and would use it to determine
whether the chat type is going to be `1` or `2`. However, there are many more chat
types, so it's important this API supports all of them.
Since we already have an enum in place, I'm changing this function to take it instead.
In addition, it also gets a `profile` parameter which is needed to implement
the status timeline functionality.
Primary motivator here was that the current `getContacts` APIs requries
a `ContactModel` which isn't always around. In fact, there's actually
no particular reason this APIs has to live on a model object.
However, to not break existing APIs I'm introducing a `getAllContacts`
API that returns all contacts as profiles, just like `contacts.getContacts`
does, without it being dependent on a `ContactModel`.
The same function is then used to add an API for returning all *added*
contacts as profiles.
By default the desktop app uses port 30305, unless a value is specifically set
in environment variable `STATUS_PORT`. For convenience of those developing the
app and running development builds, while simultaneously running production
builds (a.k.a. packaged builds, whether built locally or in CI), have `make
run` invoke `bin/nim_status_client` with `STATUS_PORT=30306`. That value can
still be overriden by manually invoking `make run` with a different value,
e.g. `make STATUS_PORT=30307 run` and `STATUS_PORT=30307 make run` are both
valid and achieve the same effect. NOTE: the port "sticks" in the database
after the first clean run, so when changing ports developers will need to
delete the data dir within their local repository, else the existing database
for dev builds will be stuck using whatever port was used previously. In the
future, we can figure out a means to always update the port setting in the
database just after the login event (but see #1505).
Also, for development builds use an icon (for the running app) that is
orangered (`#ff4500`) instead of the official blue color. This makes it much
easier to select between a running production instance and development instance
when Cmd-Tab'ing (on macOS, or equiv on Linux and Windows) through open
applications. Not all icons displayed at runtime have been changed in this
manner for development builds, just the main application icon, and that seems
to be sufficient to achieve the desired effect; though in the future we could
do similar for notification icon, menu bar icon, etc.
When dealing with Timeline and Profile chat data, the `HEAD~1` would break
because we're trying to access `ChatType(4)` inside our `toChat` API.
To fix this issue, we have to make `ChatType` aware of `4` and `5` which are
`Profile` and `Timeline` respectively.
YouTube link unfurling was not working for a couple reasons.
There were two main parts fixed:
1. QML context for messages pertaining to linkUrls and imageUrls was changed from implicit to explicit. By this, I mean that any time we referenced linkUrls/imageUrls, we were relying on the knowledge that those values would be populated by some parent context several levels up. Now, we are referring to properties that have been explicitly defined on the components. This offers the ability to reuse components, and makes reading the code and debugging much easier.
2. Error handling has been added to getting link preview data. An unhandled "error" was thrown each time a link that wasn't whitelisted was passed in, causing the app to crash. For example, when a link to a tenor gif was posted in the chat, that URL was not whitelisted, causing the app to crash.
In the context of Windows packaged builds, this is consistent with other
resources needed by the application; organizing them in this way keeps the
top-level directory of Windows packaged builds clear of files that most users
should never have to see or think about.
In timeline status update messages we want to render the ENS name next to a
local nickname in case it exists. This commit extends the `UsernameLabel` to do
just that.
Closes#1488
Allow environmental override at runtime. Also, in the Makefile set a free-tier
default token so that setting up an Infura account isn't strictly necessary for
community contributors to build the app, even though in our docs it should be
recommended they do so.
Core contributors should setup their own free-tier Infura account, create a
key, and set it in the environment variable INFURA_TOKEN in their environment
used to build the desktop app locally.
There is one aspect of this work that is incomplete. Ideally, in the handler
for the `login` event the relevant settings in the database should always be
updated with the resolved Infura key. However, when calling
`getSetting[string](Setting.Networks_Networks)` in the handler it causes a
segfault every time. Neither the reason for the crash nor a workaround have
been worked out at this time.
fix#898
The segmentation fault occured because the RPC response returned json with an error message as oppossed to the usual data required to update the chat. Since the section of the code didn't handle this error message it caused the app to crash. I've handled this error to show an error alert box by emitting a event
Add keyboard shortcuts according to https://notes.status.im/02cfVf1KQLeQU2SqrIi9tw
fix: update chat message bubbles
- Align emojis to middle of text
- Add line-height as per design
- Properly support RTL languages (right-aligned) and LTR languages (left-aligned)
- Remove unneeded non-breaking space at the beginning of current user messages
- Properly support markdown for bold, strikethrough, and italic
- Fix text being removed when in between strikethrough markdown (~~)
fix: emoji resolution update for high resolution monitors
- Emojis now use the 72x72 original set, but are down-scaled to 20x20 (in chat bubbles) or 22x22 in other places, effectively tripling their pixel density
feat: handle new lines in blockquote
Handle new lines in blockquote so that messages display correctly.
Also, add functionality when a new line is entered in to the chat input, if it's inside a blockquote, a new ">" will be added automatically. This is also handled when backspace is entered.
feat: update xss to support full qt html4 table and table-cell attributes
The transaction component's `reset` functionality was meant ot reset a form when the modal was closed. It was difficult to manage and added extra overhead for each additional transaction modal created.
Instead of using reset functions, we can use Loaders to load and destroy the modal's as they are opened and closed. We do not need to keep them in memory and then also reset their functions. It creates a smaller memory footprint to destroy the object and reload on open.
feat: load gas prediction prices asynchronously
We were previously displaying an address in the "to" field for TransactionPreview. Instead, this is meant to be a contact view.
- Fix ContactSelector to trigger selectedContactChanged
- Fix RecipientSelector > ContactSelector to trigger resolveEns from outside call to prevent infinite loop from the above fix
- Add alias to pre-selected contact for the Contact view of TransactionPreview
- Add option to change debounce delay so that when values are pre-selected (readonly), there is no delay before resolution.
- Fix missing tx data param in walletModel.estimateGas
fix: SignTransactionModal - set default focused account when none is found
refactor: move token lookup from QML to nim in the toMessage procedure.
fix: 1:1 tx requests - handle case where token contract is not found (ie sending SNT from mainnet and receiving message on testnet)
feat: error checking for building a token transaction
feat: TransactionPreview - add a validation check that disallows continuation if the selected "from" account has insufficient funds
I noticed that the 1:1 chat commands were not able to send token transactions due to "intrinsic gas too low" error. I quickly realised there there were a few components missing, which have been fixed.
*feat: update the 1:1 chat commands transaction modal to allow editing of the from account and network fee*
The TransactionStackGroup was updated slightly to allow manual control of back/next actions.
Fixes#870.
*fix: Create distinct modal transaction actions*
Previously, adding `Connection`s for the `walletModel.transactionWasSent` signal in different dialogs would cause the signal to be handled in the wrong dialog. The solution was to pass a `uuid` from the requesting dialog, and include the `uuid` in the response, so that only requests that were requested from the dialog would be handled.
*fix: update 1:1 translations*
All the translations were not being translated for me. I noticed that they did not exist in the `.ts` translation files either.
- Create privilege dialogs dynamically for each privilege requested
- Check if a privilege has been granted before to determine if dialog must be shown or not
- If dapp is allowed to use privilege, save it in the settings
- Create privilege dialogs dynamically for each privilege requested
- Check if a privilege has been granted before to determine if dialog must be shown or not
- If dapp is allowed to use privilege, save it in the settings
Jonathan Rainville
Pascal Precht
Eric Mastro
Michael Bradley, Jr
Richard Ramos
staked-smart-ace
ace-smart
Malik Al-Jabr
Iuri Matias