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.
fork-5.53.8
Greyson Parrelli 2020-10-12 10:09:35 -04:00
rodzic f784dab868
commit 1baddbb40e
2 zmienionych plików z 6 dodań i 3 usunięć

Wyświetl plik

@ -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()) {

Wyświetl plik

@ -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() {