Skip to content

Conversation

Cramsden
Copy link
Contributor

@Cramsden Cramsden commented Oct 8, 2025

📜 Tickets

Jira ticket
Github issue
Jira ticket
Github issue

💡 Description

Clean up remove tab logic so we are only doing the necessary tab persistence. Everywhere in the tab manager code we are persisting data more times than we need to. We should not need to re-select the tab and persist tab session data for each tab we remove.

This update:

  1. Save backup tab data for undo tab deletion (only available on iPad)
  2. Persists tab session data for currently selected tab to maintain scroll position updates
  3. Loop through current version tabs and delete them
  4. If you are in private mode update selected tab to current recently selected normal tab
  5. If you are not in private mode create a new tab and select it

There is no need to commit changes after this because select tab preserves tabs

With 200 tabs this greatly increases the tab performance.

TabManager.removeAllTabs
Before: 5.15 s 37.7%
After: 41.00 ms  3.4%

🎥 Demos

Before After
Demo

📝 Checklist

  • I filled in the ticket numbers and a description of my work
  • I updated the PR name to follow our PR naming guidelines
  • I ensured unit tests pass and wrote tests for new code
  • If working on UI, I checked and implemented accessibility (Dynamic Text and VoiceOver)
  • If adding telemetry, I read the data stewardship requirements and will request a data review
  • If adding or modifying strings, I read the guidelines and will request a string review from l10n
  • If needed, I updated documentation and added comments to complex code

Comment on lines 256 to 261
for (index, tab) in currentModeTabs.enumerated() {
self.removeTab(tab, flushToDisk: false)
if tab == currentModeTabs.last {
self.updateSelectedTabAfterRemovalOf(tab, deletedIndex: index)
}
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Cramsden I haven't had a chance to take a close look, is this effectively the same basic approach as #26782? FYI I saw a weird index-related crash when testing my optimization, which I was concerned about. It was intermittent though and I still haven't had time to verify whether it was related to the optimization changes.

@lmarceau
Copy link
Contributor

FYI just in case, there's a contributor PR opened for that same area of the code.

@Cramsden Cramsden force-pushed the cr/FXIOS-12300_fix-remove-tab-slowness branch from 018d354 to eda3116 Compare October 14, 2025 16:47
@Cramsden Cramsden marked this pull request as ready for review October 14, 2025 16:57
@Cramsden Cramsden requested a review from a team as a code owner October 14, 2025 16:57
@Cramsden Cramsden requested a review from mdotb-moz October 14, 2025 16:57
@mobiletest-ci-bot
Copy link

Messages
📖 Project coverage: 37.83%

💪 Quality guardian

1 tests files modified. You're a champion of test coverage! 🚀

🧹 Tidy commit

Just 2 file(s) touched. Thanks for keeping it clean and review-friendly!

💬 Description craftsman

Great PR description! Reviewers salute you 🫡

✅ Per-file coverage

All changed files meet the threshold of 35.0%.

Client.app: Coverage: 37.24

File Coverage
TabManagerImplementation.swift 55.35%

Generated by 🚫 Danger Swift against eda3116

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.

4 participants