Fixes#2448.
Currently, if a wrong password is entered when generating a wallet account, the app will crash due to attempting to decode a `GeneratedAccount ` from an rpc response containing only an error.
With this PR, we are detecting if an error is returned in the response, and if so, raising a StatusGoException. This exception is caught in the call chain, and translated in to a `StatusGoError` which is serialised and sent to the QML view, where it is parsed and displayed as an invalid password error in the input box.
refactor: remove string return values as error messages in wallet model
In the wallet model, we were passing back empty strings for no error, or an error as a string. This is not only confusing, but does not benefit from leaning on the compiler and strong types. One has to read the entire code to understand if a string result is returned when there is no error instead of implicitly being able to understand there is no return type.
To alleviate this, account creation fundtions that do not need to return a value have been changed to a void return type, and raise `StatusGoException` if there is an error encountered. This can be caught in the call chain and used as necessary (ie to pass to QML).
refactor: move invalid password string detection to Utils
Currently, we are reading returned view model values and checking to see if they include a known string from Status Go that means there was an invalid password used. This string was placed in the codebased in mulitple locations.
This PR moves the string check to a Utils function and updates all the references to use the function in Utils.
Fixes: #2364
The Send Message button click event was erroring due to a refactor that had been done to allow for changing app sections.
This has been updated to follow the current way to change app sections.
fix: “Send Message” button crash in communities
This required switching from communities to normal view.
fix: crash when clicking channel link in community message
When a message in communities contains a link to another channel (ie #otherchannel), the search for this channel needed to be updated to also search for the channel by name, allowing for switching between channels within a community by message link. Additionally, when in a community, if the channel was located in a normal chat, it will switch the view to the normal chat after being found.
Fixes: #2257.
If a user had selected a watch-only address in the wallet, the backend `walletModel.currentAccount` property would also change. When loading a transaction modal, this property was used to set the `selectedAccount` value for the “from” `AccountSelector`, regardless if the account was a watch-only address.
This PR updates the logic for `selectedAccount` such that it will only allow the account to be selected if it is not a watch-only account.
This commit introces global settings that apply across accounts used
inside the application. This is useful when settings like the selected
locale should b the same across all accounts.
Closes#2144
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
When the communities code was moved into its own view in https://github.com/status-im/status-desktop/commit/b38d1df59
it broke the functionality to join communities again.
Qt complains that the Nim API in use `chatsModel.communities.joinCommunity`
expects two parameters, when it's call with just one.
This is unexpected because the API in question set a default value
for its second parameter.
To make this work again, we have to make sure the `setActive`
parameter is supplied every time we call the API from
within QML.
Also, worth noting that this is not the first time we're running into
a scenario like this.
For an unknown reason, when the `chatLogView` ListView uses
a `verticalLayoutDirection: BottomToTop`, it prevents the application
from successfully rendering during login and crashes.
From debugging this, we know that this only happens when the above
condition applies *and* when a `DelegateModel` is used.
The delegate doesn't even need proper data, it application would still
crash.
We found out that the crash can be avoided when another `ListView` exists
in this component (however it's unclear why).
For now this commit adds such a placeholder `ListView` until it
we know more about what's going on.
In some cases inside of 1-on-1 chats, the fake messages added to
the beginning of the message list, wouldn't determine the correct
username of the contact in question.
This commit explicitly calls `chatsModel.userNameOrAlias()` instead
of relying on `activeChannel.name` which tries to do the same.
This commit adds a menu item to the message context menu to
copy links that may exist inside of a message.
There are three possible scenarios:
1. There's no link in the message, which causes the menu to not
render the dedicated menu item at all
2. There's one link in the message, which renders an additional
`Action` with a copy-to-clipboard functionality
3. There are multiple links in a single message. This adds a
nested `PopupMenu` in the existing menu with menu items for each
link extracted from the message
To make this work there were some changes in the `PopupMenu` component
needed, as it wasn't take the sub menu's `enabled` state into account
properly. This makde it always render nested menus even when they
should've been invisible.
Closes: #1733
This was missing in one of our previous PRs and causes the
channel context menu to not function properly e.g. when deleting
chats, it currently always deletes the first chat in the channel list
instead of the active channel.
redesigns the compact mode to have a nice hover, easier replying and adding reactions and more
Missing parts are aligning chat command, images and unfurlings, redesigning mentions and the channel list and also trying to find a way to re-enable link hovers in the text
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
This commit introduces a new `ChannelContextMenu` component that can be reused
in different places, such as the channel list, as well as the chat bar.
At the moment we use two different pop up menus that also show two different
set of menu options. By using `ChanelContextMenu` in both of these places,
we get the same menu and same experience.
Closes#1711
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.
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.
Prior to this commit, the function was expected on a `chatView` QML object.
This has worked out so far because the places where the API is used were always
living inside `ChatLayout`.
With the new timeline however, this is no longer the case so we have to make sure
that the API is available to other views as well.
This commit introduces some `MouseArea`s so components inside the
`StatusUpdate` component cancel it out by having a higher `z`.
Also, in some cases we need to conditionally set the `root.hovered` property
to ensure the values get inverted correctly, otherwise it causes undesired
flicker effects.
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
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 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
This is done because there's gonna be a case where this connection causes errors
because the component expects `NormalMessage` to be a parent of this component.
When used in future StatusUpdates, there's no `NormalMessage`. Unfortunately,
disabling the connection based on a condition doesn't remove the error, so we have
to move this code out entirely
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
BalanceValidator and GasValidator have been moved outside of the TransactionPreview component, because there are some transaction modals that may not need them to be baked in to TransactionPreview. It is useful to have these components on the tx preview step only when we start the process on the preview step.
Fixes#1202
I had to revert the loader changes that switched from/to as it was causes quite a lot of logistical complexity. Instead of using Loaders, we are setting the type of account (account or contact), and it is being displayed appropriately. There is a very slight deviation from the design, however it is consistent with the design for other transaction previews.
feat: add BalanceValidator
Shows an exclamation icon next to the "from" account when the balance for the requested asset is too low.
This is useful when the user starts the transaction wizard on the TransactionPreview step.
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.
Jonathan Rainville
Richard Ramos
Eric Mastro
Pascal Precht
Iuri Matias
ace-smart
Malik Al-Jabr
staked-smart-ace
Michael Bradley, Jr