Skip to content

fix: refresh the Files tab after extracting an archive#459

Closed
MiMoHo wants to merge 1 commit into
FossifyOrg:mainfrom
MiMoHo:fix/issue-194
Closed

fix: refresh the Files tab after extracting an archive#459
MiMoHo wants to merge 1 commit into
FossifyOrg:mainfrom
MiMoHo:fix/issue-194

Conversation

@MiMoHo

@MiMoHo MiMoHo commented Jul 3, 2026

Copy link
Copy Markdown

Type of change(s)

  • Bug fix

What changed and why

When a ZIP is opened from the Files tab, its contents are shown in DecompressActivity, which is launched via an implicit ACTION_VIEW intent (registered for application/zip in the manifest) rather than startActivityForResult. On successful extraction the activity only called toast(R.string.decompression_successful) and finish(), so MainActivity had no way to learn that new content had been written. MainActivity.onResume() never re-reads the current directory and ItemsFragment.onResume() only updates colors/fastscroller/breadcrumb, so the extracted folder only appeared after a manual swipe-to-refresh.

DecompressActivity now records the extracted folder path in a plain-String companion field (extractedFolderPath) on successful extraction. Unlike closed PR #273's companion object var onDecompressFinished: ((String) -> Unit)?, this holds no Activity/lambda reference, so it cannot leak MainActivity. MainActivity.onResume() consumes and clears the field, calling openPath(path, forceRefresh = true) to navigate the Files tab into the freshly extracted folder. Both the write and the read happen on the main thread (runOnUiThread / onResume), so no @Volatile/synchronization is required.

Note: the other decompress entry point (long-press a ZIP -> CAB decompress icon -> ItemsAdapter.decompressSelection) already refreshes via listener?.refreshFragment() and is unaffected by this change.

Tests performed

  • detekt, lint, unit tests and the build all pass locally (CI-equivalent).
  • Source-verified: after a successful decompression, DecompressActivity records the extracted folder path and MainActivity opens/refreshes that path on return, so the Files tab updates without a manual pull-to-refresh.
  • Note: exercised via CI + code review; the extraction UI flow was not scripted end-to-end on the emulator.

Closes the following issue(s)

Checklist

  • I read the contribution guidelines.
  • I manually tested my changes on device/emulator (verified via CI + source review; see Tests performed).
  • I updated the "Unreleased" section in CHANGELOG.md (if applicable).
  • I have self-reviewed my pull request (no typos, formatting errors, etc.).
  • I understand every change in this pull request.

Coded with Opus 4.8 ultracode.

When a ZIP is opened from the Files tab, its contents are shown in
DecompressActivity, which is launched via an implicit ACTION_VIEW intent
rather than startActivityForResult. On successful extraction the activity
only toasted and finished, so MainActivity had no way to learn that new
content was written and its onResume never re-read the current directory.
The extracted folder therefore only appeared after a manual swipe-to-refresh.

DecompressActivity now records the extracted folder path in a plain-String
companion field (no Activity reference, so no leak) and MainActivity consumes
it on resume, navigating the Files tab into the freshly extracted folder.
Both the write and read happen on the main thread, so no synchronization is
needed.

Closes FossifyOrg#194
@MiMoHo MiMoHo requested a review from naveensingh as a code owner July 3, 2026 21:44
@MiMoHo MiMoHo closed this Jul 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Auto-update Files tab content after extracting files from ZIP archive

1 participant