github-starred/android
2
0
Fork 0
mirror of https://github.com/bitwarden/android.git synced 2026-03-15 06:59:05 -05:00
Code Issues 144 Packages Projects Releases 116 Wiki Activity

[PR #1455] [MERGED] Bugfixes for lock block when setting timeout to immediate #2902

New Issue
Closed
opened 2025-11-26 23:25:42 -06:00 by GiteaMirror · 0 comments
GiteaMirror commented 2025-11-26 23:25:42 -06:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/bitwarden/android/pull/1455
Author: @mpbw2
Created: 7/10/2021
Status: ✅ Merged
Merged: 7/12/2021
Merged by: @mpbw2

Base: master ← Head: bugfix-lock-immediate

📝 Commits (1)

  • bb3a941 bugfixes for lock block when setting timeout to immediate

📊 Changes

6 files changed (+32 additions, -13 deletions)

View changed files

📝 src/Android/MainActivity.cs (+5 -0)
📝 src/App/Pages/Send/SendAddEditPage.xaml.cs (+5 -2)
📝 src/App/Pages/Send/SendAddEditPageViewModel.cs (+1 -9)
📝 src/App/Pages/Vault/AddEditPage.xaml.cs (+4 -1)
📝 src/App/Pages/Vault/AutofillCiphersPage.xaml.cs (+5 -1)
📝 src/App/Utilities/AppHelpers.cs (+12 -0)

📄 Description

Recent changes caused the app to lock instantly when adding a new cipher or Send from within the app when the vault timeout is set to immediate. As locking is handled on sleep instead of on resume when the timeout is set to immediate, some additional intelligence was needed to make sure activities that support launching via intent (autofill and Send) don't perform lock checks on launch if the timeout is set to immediate (as the app will already be locked when the user exited previously).

While working on this, a previous fix regarding back button handling in Send stopped working. Further investigation revealed the launch intent was being re-delivered when resuming from the app switcher. A simple check for the intent's ActivityFlags.LaunchedFromHistory allows us to skip delivery if it's not triggered via the original share action. This seems to be more reliable and eliminates the need for a dedicated CloseMainApp() method, so that was reverted.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/bitwarden/android/pull/1455 **Author:** [@mpbw2](https://github.com/mpbw2) **Created:** 7/10/2021 **Status:** ✅ Merged **Merged:** 7/12/2021 **Merged by:** [@mpbw2](https://github.com/mpbw2) **Base:** `master` ← **Head:** `bugfix-lock-immediate` --- ### 📝 Commits (1) - [`bb3a941`](https://github.com/bitwarden/android/commit/bb3a941a18495e57e53cdb17e7dca07d9e2804a3) bugfixes for lock block when setting timeout to immediate ### 📊 Changes **6 files changed** (+32 additions, -13 deletions) <details> <summary>View changed files</summary> 📝 `src/Android/MainActivity.cs` (+5 -0) 📝 `src/App/Pages/Send/SendAddEditPage.xaml.cs` (+5 -2) 📝 `src/App/Pages/Send/SendAddEditPageViewModel.cs` (+1 -9) 📝 `src/App/Pages/Vault/AddEditPage.xaml.cs` (+4 -1) 📝 `src/App/Pages/Vault/AutofillCiphersPage.xaml.cs` (+5 -1) 📝 `src/App/Utilities/AppHelpers.cs` (+12 -0) </details> ### 📄 Description Recent changes caused the app to lock instantly when adding a new cipher or Send from within the app when the vault timeout is set to immediate. As locking is handled on sleep instead of on resume when the timeout is set to immediate, some additional intelligence was needed to make sure activities that support launching via intent (autofill and Send) don't perform lock checks on launch if the timeout is set to immediate (as the app will already be locked when the user exited previously). While working on this, a previous fix regarding back button handling in Send stopped working. Further investigation revealed the launch intent was being re-delivered when resuming from the app switcher. A simple check for the intent's `ActivityFlags.LaunchedFromHistory` allows us to skip delivery if it's not triggered via the original share action. This seems to be more reliable and eliminates the need for a dedicated `CloseMainApp()` method, so that was reverted. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
GiteaMirror added the pull-request label 2025-11-26 23:25:42 -06:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
app:authenticator
app:password-manager
bug
bug-passkey
customer-support
duplicate
enhancement
good first issue
help wanted
needs-reply
needs-response
pull-request
Mirrored from GitHub Pull Request
 question
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/android#2902
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?