-
-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add invisible decryption config flag and show invisible crypto decryption errors #50
base: develop
Are you sure you want to change the base?
Conversation
034cedc
to
e1081e4
Compare
Ah. Forgot that SonarCloud doesn't take into account the end-to-end tests, so I'll have to add jest tests. |
e1081e4
to
9afdc75
Compare
return _t("timeline|decryption_failure|sender_identity_previously_verified"); | ||
|
||
case DecryptionFailureCode.UNSIGNED_SENDER_DEVICE: | ||
// TODO: event should be hidden instead of showing this error (only |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this needs to be done by checking the decryption failure code in EventTile.tsx
, and if it is this code, then render an empty tile?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably, but I'd like us to kick this down the road for a bit. Let's display the error for now and think about hiding them later.
(it's the same as HISTORICAL_MESSAGE_USER_NOT_JOINED)
@@ -10,3 +10,7 @@ Please see LICENSE files in the repository root for full details. | |||
color: $secondary-content; | |||
font-style: italic; | |||
} | |||
|
|||
.mx_DecryptionFailureVerifiedIdentityChanged { | |||
color: red; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like we shouldn't be hardcoding colors like this
// A placeholder element for messages that could not be decrypted | ||
export const DecryptionFailureBody = forwardRef<HTMLDivElement, IBodyProps>(({ mxEvent }, ref): React.JSX.Element => { | ||
const verificationState = useContext(LocalDeviceVerificationStateContext); | ||
return ( | ||
<div className="mx_DecryptionFailureBody mx_EventTile_content" ref={ref}> | ||
<div className={"mx_DecryptionFailureBody mx_EventTile_content" + getErrorExtraClass(mxEvent)} ref={ref}> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should use classnames
here rather than doing string manipulation.
"feature_invisible_crypto": { | ||
isFeature: true, | ||
labsGroup: LabGroup.Encryption, | ||
controller: new InvisibleCryptoController(), | ||
displayName: _td("labs|invisible_crypto"), | ||
description: _td("labs|invisible_crypto_description"), | ||
supportedLevels: LEVELS_DEVICE_ONLY_SETTINGS_WITH_CONFIG_PRIORITISED, | ||
supportedLevelsAreOrdered: true, | ||
default: false, | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we probably need two settings -- one for "invisible crypto", and one for "transition mode" ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I wasn't sure how best to represent this. Having two separate toggles for three levels seems wrong (e.g. what do we do if both "invisible" and "transition" are enabled). I think that ideally, this would be a dropdown or something that would allow us to select one of the three levels, but I don't how to do that in settings, or if it's even possible with feature flags. I think that if it isn't possible for feature flags, my second preference would be for the feature flag to be to enable "new cryptography modes" or some such, which would enable a selector somewhere else to select the mode. But, basically, I didn't have time to sufficiently investigate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I suspect probably a custom labs flag that's actually a drop down 9and maybe not actually a labs flag but manually put into the labs section?) That or a labs flag to enable another setting in the crypto section, although that risks people not realising they've turned the labs flag on.
Either way, would you want this PR is as it is with no option for transition mode or do we want to wait?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could we maybe move the changes to DecryptionFailureBody into a separate PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, one PR for the config setting, and one PR for the display changes? Possibly, but I suspect that the config setting PR will have a lack of code worth testing, which would cause SonarCloud to complain. I'll rewrite this PR so that it has two commits - one for the config setting and one for the display changes, so that it can be split into two PRs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I discovered some tests for settings, and added one for invisible crypto. So maybe SonarCloud would be happy with a PR for just the setting. But I've run out of time to split it into a separate PR. But it is now in two commits.
de8c5fb
to
c2fc124
Compare
A couple of issue with this PR:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems plausible otherwise
"feature_invisible_crypto": { | ||
isFeature: true, | ||
labsGroup: LabGroup.Encryption, | ||
controller: new InvisibleCryptoController(), | ||
displayName: _td("labs|invisible_crypto"), | ||
description: _td("labs|invisible_crypto_description"), | ||
supportedLevels: LEVELS_DEVICE_ONLY_SETTINGS_WITH_CONFIG_PRIORITISED, | ||
supportedLevelsAreOrdered: true, | ||
default: false, | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I suspect probably a custom labs flag that's actually a drop down 9and maybe not actually a labs flag but manually put into the labs section?) That or a labs flag to enable another setting in the crypto section, although that risks people not realising they've turned the labs flag on.
Either way, would you want this PR is as it is with no option for transition mode or do we want to wait?
Depends on matrix-org/matrix-js-sdk#4407
Adds an "invisible crypto" setting. When enabled, sets the crypto mode in the client crypto API. Shows the appropriate error message when returned from the crypto API.
Checklist
public
/exported
symbols have accurate TSDoc documentation.