Fix some oddities with message request behavior.

There was a weird case where how our intent checking could behave
differently when coming from search. There's also some funny
interactions where backups, where because the 'time message requests was
enabled' is reset to System.currentTimeMillis() post-restore, we thought
there were always 'pre-message-request messages'. Only mattered when
profileSharing is also disabled, so impact isn't huge. Given a lot of
this UI is going away soon, rather than doing the complicated thing of
backing up the true timestamp, I just default it to 0 to mitigate
things.
master
Greyson Parrelli 2020-10-12 10:09:35 -04:00
parent f784dab868
commit 1baddbb40e
2 changed files with 6 additions and 3 deletions

View File

@ -3272,7 +3272,10 @@ public class ConversationActivity extends PassphraseRequiredActivity
}
private void presentMessageRequestDisplayState(@NonNull MessageRequestViewModel.DisplayState displayState) {
if (getIntent().hasExtra(TEXT_EXTRA) || getIntent().hasExtra(MEDIA_EXTRA) || getIntent().hasExtra(STICKER_EXTRA)) {
if ((getIntent().hasExtra(TEXT_EXTRA) && !Util.isEmpty(getIntent().getStringExtra(TEXT_EXTRA))) ||
getIntent().hasExtra(MEDIA_EXTRA) ||
getIntent().hasExtra(STICKER_EXTRA))
{
Log.d(TAG, "[presentMessageRequestDisplayState] Have extra, so ignoring provided state.");
messageRequestBottomView.setVisibility(View.GONE);
} else if (isPushGroupV1Conversation() && !isActiveGroup()) {

View File

@ -16,7 +16,7 @@ public final class MiscellaneousValues extends SignalStoreValues {
@Override
void onFirstEverAppLaunch() {
putLong(MESSAGE_REQUEST_ENABLE_TIME, System.currentTimeMillis());
putLong(MESSAGE_REQUEST_ENABLE_TIME, 0);
}
public long getLastPrekeyRefreshTime() {
@ -28,7 +28,7 @@ public final class MiscellaneousValues extends SignalStoreValues {
}
public long getMessageRequestEnableTime() {
return getLong(MESSAGE_REQUEST_ENABLE_TIME, System.currentTimeMillis());
return getLong(MESSAGE_REQUEST_ENABLE_TIME, 0);
}
public long getLastProfileRefreshTime() {