Skip to content

Conversation

@ih-codes
Copy link
Collaborator

📜 Tickets

Jira ticket
Github issue

💡 Description

Fix under-specified protocols by adding isolation details: AddressToolbarDelegate, EmptyPrivateTabView, InsetUpdatable, PhotonActionSheetContainerCellDelegate, NavigationController.

Screenshot 2025-09-25 at 4 02 45 PM

cc @Cramsden @lmarceau @dataports | Swift 6 Migration

📝 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

…bView, InsetUpdatable, PhotonActionSheetContainerCellDelegate, NavigationController.
@ih-codes ih-codes requested a review from yoanarios September 26, 2025 16:07
@ih-codes ih-codes requested a review from a team as a code owner September 26, 2025 16:07
Copy link
Contributor

@yoanarios yoanarios left a comment

Choose a reason for hiding this comment

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

LGTM I just have a quick question

import Shared
import ComponentLibrary

@MainActor
Copy link
Contributor

Choose a reason for hiding this comment

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

Just a quick question: how should we decide when to annotate an entire protocol with @mainactor versus adding it only to individual methods or conforming types (like in AddressToolbarDelegate above)?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I usually think of it like this: if it is a protocol that will only ever apply to a UI class, then it's worth annotating the entire protocol as a shorthand (in this case it's for a tab view). This is because Apple has @MainActor isolation already on all its UI code.

But if it's a delegate protocol where it's possible that a non-UI class (which would therefore not have main actor isolation) might implement it, I only mark the methods and properties inside the protocol individually. This is less restrictive, as it tells the compiler the entire type is not required to be @MainActor.

I have a playground demo and more detailed explanation pinned here in slack!

import Foundation
import UIKit

public protocol AddressToolbarDelegate: AnyObject {
Copy link
Contributor

Choose a reason for hiding this comment

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

Regarding below comment, I would think toolbar relates to UI and that whole protocol should be @MainActor?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

The toolbar is UI, but a delegate could theoretically be a service or manager class that doesn't need to be entirely main actor, or maybe even shouldn't be main actor isolated if it's doing async work. 👀

In this case though I agree it's very likely going to be a UI subclass that conforms to it (in fact a UIView class is the conforming class in our code). That said, I thought I'd put in a little extra effort to be less restrictive just in case.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I'm not super familiar with this area of the code so if it's really obvious this should be only UI classes conforming to this protocol, then it would be totally reasonable to @MainActor the whole thing!

Copy link
Contributor

Choose a reason for hiding this comment

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

We can ask @thatswinnie opinion on it 👀 Not a blocker thought for this PR

@mobiletest-ci-bot
Copy link

Messages
📖 Project coverage: 38.49%

💪 Quality guardian

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

🌱 Tiny but mighty

Only 29 line(s) changed. Fast to review, faster to land! 🚀

🙌 Friday high-five

Thanks for pushing us across the finish line this week! 🙌

💬 Description craftsman

Great PR description! Reviewers salute you 🫡

Client.app: Coverage: 37.35

File Coverage
ExperimentRemoteTabsEmptyView.swift 0.0% ⚠️
ExperimentEmptyPrivateTabsView.swift 0.0% ⚠️
NavigationController.swift 0.0% ⚠️
PhotonActionSheetContainerCell.swift 0.0% ⚠️

ToolbarKit: Coverage: 63.15

File Coverage
BrowserNavigationToolbar.swift 92.44%

Generated by 🚫 Danger Swift against 6afc5a3

@ih-codes ih-codes merged commit b6cf0f9 into epic-branch/swift-migration Sep 26, 2025
8 checks passed
@ih-codes ih-codes deleted the ih/FXIOS-12796-under-specified-protocols-1 branch September 26, 2025 20:12
ih-codes added a commit that referenced this pull request Sep 26, 2025
… from last week (#5) (#29657)

* Refactor FXIOS-13511 [Swift 6] Remove Equatable from AppState and other redux states (#29495)

* Remove unneeded equatable conformance on redux states

* Fix tests

* Fix test

* Refactor FXIOS-13532 [Swift 6 Migration] Fix strict concurrency errors related to Notifications  (#29514)

Fun stuff

* Refactor FXIOS-13502 [Swift 6 Migration] Fix main actor isolation warnings in MozillaRustComponents (#29426)

"Fix" main actor isolation warnings in MozillaRustComponents with a workaround for setting accessibility identifiers to prevent larger impacts and errors in Client generated code.

* Refactor FXIOS-13511 [Swift 6] Move Tab to MainActor and resolve strict concurrency warnings (#29497)

* Refactor FXIOS-13511 [Swift 6] Remove Equatable from AppState and other redux states (#29495)

* Remove unneeded equatable conformance on redux states

* Fix tests

* Fix test

* Refactor FXIOS-13532 [Swift 6 Migration] Fix strict concurrency errors related to Notifications  (#29514)

Fun stuff

* first pass of isolating tab to the main actor

* Clean up tests and push commented out code

* fix additional warnings

* Clean up remaining warnings

* fix tests

* add missing ticket numbers

* resolve introduced warning

---------

Co-authored-by: lmarceau <lmarceau@mozilla.com>

* Refactor FXIOS-13532 #29411 [Swift 6 Migration] AppDelegate + PushNotification (#29590)

* Fix for Constellation update

* Fix UNUserNotificationCenterDelegate methods

* Fix tests

* Refactor FXIOS-13235 [Swift 6 Migration] Enable strict concurrency checking in SummarizerKit (#29575)

* Enable strict concurrency in SummarizerKit.

* Fix closure `Sendable` warnings.

* Fix some other warnings. Suppress others with FIXME tickets.

* Refactor FXIOS-13463 #29256 [Swift 6 Migration] WebEngine @mainactor (#29393)

* Policy decider

* Make main actor

* @mainactor stuff

* Fix the tests

* Adjust Client

* Add ticket number

* Adjust following comments

* Refactor FXIOS-12796 [Swift 6 Migration] Fix more under-specified protocols (#29650)

* Fix under-specified protocols: AddressToolbarDelegate, EmptyPrivateTabView, InsetUpdatable, PhotonActionSheetContainerCellDelegate, NavigationController.

* Fix unit tests.

* Refactor FXIOS-13502 [Swift 6 Migration] Fix or suppress `Sendable` and misc. warnings in MozillaRustComponents (round 1) (#29425)

* Fix or suppress Sendable warnings in MozillaRustComponents.

* Janky workaround for main actor isolation warning.

* Update some Rust Components Sendable callbacks with @mainactor as well so the Client can reason better about main actor isolation.

* Refactor FXIOS-13511 [Swift 6] Additional Strict Concurrency Clean up for Tab and Friends (#29628)

* Additional tab clean up

* Isolate UserScriptManager to main actor

* fix tests

* turn off strict concurrency

* more main actor isolation

* resolve introduced warnings

---------

Co-authored-by: Carson Ramsden <carsonramsden@gmail.com>
Co-authored-by: lmarceau <lmarceau@mozilla.com>
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.

5 participants