UI does not change theme while in Settings when system theme changes

[junbio]

Steps to reproduce

1. Open settings
2. Open Control Center
3. Hold on brightness control
4. Enable dark mode

Expected behavior

UI switches to dark mode

Actual behavior

UI remains light

Device & build information

• Device: iPhone X (iOS 15.2.1)
• Build version: Firefox Daylight 96.0 (7403)
  1. Notes
     Attachments:

┆Issue is synchronized with this Jira Task

[junbio]

Since BrowserViewController is in charge of handling system theme changes, and view controllers being presented in full screen delays underlying view controllers from changing their interface style, the UI does not switch. Changing the presentation style to form sheet does allow underlying view controllers to change their trait collections immediately, but this is not ideal. Doing this also fixes #9788.

[junbio]

Upon further examination, this bug occurs because some views are being presented with .fullScreen instead of .overFullScreen. There's a particular comment that explains this decision:

firefox-ios/Client/Frontend/Widgets/PhotonActionSheet/AppMenu.swift

Lines 66 to 69 in e2356c7

	// On iPhone iOS13 the WKWebview crashes while presenting file picker if its not full screen. Ref #6232
	if UIDevice.current.userInterfaceIdiom == .phone {
	controller.modalPresentationStyle = .fullScreen
	}

Do you know if this is still necessary? @lmarceau

[lmarceau]

@junbio This was brought in PR #6484 to fix issue #6232. It looks like something that still applies today, maybe worth checking to confirm? It can be tested by having a sync account to add an account picture.

[junbio]

If you open Settings by tapping the "Customize Homescreen" button, it is presented using .overFullScreen and not .fullScreen. If you navigate to the account picker in the current version of Firefox, I can confirm it doesn't crash when uploading an image.

[lmarceau]

Interesting! And that was on iOS 13?

And what about if you remove the lines:

firefox-ios/Client/Frontend/Widgets/PhotonActionSheet/AppMenu.swift

Lines 66 to 69 in e2356c7

	// On iPhone iOS13 the WKWebview crashes while presenting file picker if its not full screen. Ref #6232
	if UIDevice.current.userInterfaceIdiom == .phone {
	controller.modalPresentationStyle = .fullScreen
	}

Does it work as well by opening the settings from the bottom toolbar (and not from the "Customize Homescreen" button) - has something changed?

If it crashes in that case still, then we would need to find the answer as to why opening from "Customize Homescreen" button with .overFullScreen works and not from the bottom toolbar 🤔

[junbio]

Interesting! And that was on iOS 13?

No, the current version of iOS 15.2.1 and the current App Store version of Firefox. But since all devices that run iOS 13 can be updated to iOS 15, I was wondering if this workaround was still necessary. You can guard it so the code only runs on iOS 14 or earlier.

If it crashes in that case still, then we would need to find the answer as to why opening from "Customize Homescreen" button with .overFullScreen works and not from the bottom toolbar 🤔

I also tried changing the modal presentation style from .fullScreen to .overFullScreen in the action sheet and it doesn't crash when uploading a photo or file. This is on the iOS 15 Simulator though.

[lmarceau]

@junbio Ok well like you say we can maybe enclose this code in a version check with #available. We should keep the check to avoid that crash on iOS 13.0 devices only. Although devices can be updated, we still have some users on those OS and we're still supporting it. With that check, I would verify on iOS 14 and 15 that the crash isn't happening, on simulator and real device. I can test the part on the real device if you open a PR :)

[junbio]

I tested the current App Store version of Firefox on iOS 14.8.1 and it doesn't crash when selecting a new profile picture from Settings. Do you think iOS 14.0 is a good cutoff version?

[lmarceau]

@junbio Yeah, like in your PR I think it's ok! I'll test later this week. Thanks a lot!

[lmarceau]

This bug is fixed as part of #11825. I'll close it here and ask for this to be tested as part of that issue.