User Agent: Mozilla/5.0 (Android 13; Mobile; rv:109.0) Gecko/111.0 Firefox/111.0

Steps to reproduce:

Open any YouTube video. Watch it on full screen. While watching, you want to change quality or speed of the video so you click on settings icon on the top right corner. Now when you click on "quality" or "speed" option, the full screen mode disappears, i.e. landscape mode changes to portrait and you need to manually re-enter to full screen mode. You've to do it every time when you want to change those settings again.
(As a short note, I'm on firefox beta v 111.0b6)

Actual results:

When watching YouTube on fullscreen mode and clicking on "quality" or "speed" option from settings, the full screen mode disappears, i.e. landscape mode changes to portrait and you need to manually re-enter to full screen mode.

Expected results:

Quality or speed should have changed without exiting the full screen.

I can reproduce in Firefox and Focus Beta 111 and Nightly 112, but not Release 110 or Chrome. On my device, the video exits full screen mode, but the page orientation doesn't switch from landscape back to portrait.

user3987 originally reported this bug on Reddit: https://www.reddit.com/r/firefox/comments/11d7kys/youtube_problem_on_firefox_beta/

Could this be a regression from bug 1813416?

Makoto, Kevin suspects this bug is a regression from bug 1767449. YouTube now exits full screen in Firefox but not Chrome. Is this a bug in our code or do we need to ask YouTube to change how they handle screen orientation lock on Firefox?

This is correct behavior when screen orientation lock is unlocked by existing full screen. But this problem is that full screen is exited when something prompt is shown then actived.

Also, screen orientation lock is disabled by beta and release. So this is disabled by 111. But this occurs on 111 beta, so we need right regression range. (Firefox 109 doesn't exit fullscreen)

QA, can you please test whether this bug is reproducible in the GeckoViewExample app? If it is, can you try using mozregression to bisect which Nightly build first introduced this bug?

This bug might have landed in Nightly 111 or it might have landed in Nightly 112 and was then uplifted to Beta 111. So you should try bisecting builds between Nightly 110 (a known good version) and the latest Nightly build.

I guess that https://github.com/mozilla-mobile/firefox-android/pull/789

QA, can you please test whether this bug is reproducible in the GeckoViewExample app

I cannot reproduce this on GVE.

When I backed out https://github.com/mozilla-mobile/firefox-android/pull/789, this doesn't occur. Petru, could you look this?

Agree that this is the result of https://github.com/mozilla-mobile/firefox-android/pull/789.
We'll need to investigate more on how to keep both functionalities working.

:cpeterson :petru this is the final week of 111 beta, next week is RC week.
As mentioned above this was backported to the releases_v111 branch.
In terms of timing/impact could you consider backing out the PR you backported?

(In reply to Donal Meehan [:dmeehan] from comment #11)

:cpeterson :petru this is the final week of 111 beta, next week is RC week.
As mentioned above this was backported to the releases_v111 branch.
In terms of timing/impact could you consider backing out the PR you backported?

Petru recommends that we not back out that fix this late in the release cycle. He will investigate other approaches for fixing YouTube, so I will reassign this bug to him.

I'm clearing the qe-verify flag: Makoto found the regression, so we don't need QA to test.

Setting firefox111 back to "affected" in case we have an alternate fix we can uplift to a 111 dot release.

I think the difference here is whether the user initiated the prompt.
Arturo helped with some prompts which can be triggered programatically - Alert,TextPrompt, TimeSelection,
But we're curious if there are more.
We currently support this prompts in AC

• https://github.com/mozilla-mobile/firefox-android/blob/5b3392797a1d5042f6e3c4b1aa019daef7e2cacf/android-components/components/feature/prompts/src/main/java/mozilla/components/feature/prompts/PromptFeature.kt#L469-L488 and
• https://github.com/mozilla-mobile/firefox-android/blob/5b3392797a1d5042f6e3c4b1aa019daef7e2cacf/android-components/components/feature/prompts/src/main/java/mozilla/components/feature/prompts/PromptFeature.kt#L640-L869

@Emilio sorry for pinging you but maybe you can help with the full list of prompts which can be triggered by the website vs prompts which can be triggered only by the user?

Confirm, File, Color for sure can be triggered programmatically assuming it just comes from window.confirm(), <input type=file> and <input type=color>.

SingleChoice, MenuChoice, MultipleChoice I'm not convinced they can, but they probably should.

I'm confused tho, why do we want to exit fullscreen on any of those, independently of they being user or programmatically triggered?

Resolving and setting 112 to fixed, since the PR merged into main.
This will need a release uplift request for inclusion in a 111 dot release.

Comment on attachment 9321632 [details]
[mozilla-mobile/firefox-android] Bug 1819254 - Don't exit fullscreen for user input prompts (backport #1133) (#1151)

Beta/Release Uplift Approval Request

• User impact if declined: All prompts shown while being in fullscreen will exit fullscreen. This patch limits such scenarios.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: Open any YouTube video. Watch it on full screen. While watching, you want to change quality or speed of the video so you click on settings icon on the top right corner. Now when you click on "quality" or "speed" option, the full screen mode disappears, i.e. landscape mode changes to portrait and you need to manually re-enter to full screen mode. You've got to do it every time when you want to change those settings again.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Small change, soon to be verified by QA.
• String changes made/needed:
• Is Android affected?: Yes

Verified as fixed on the latest Nightly 112.0a1 (2023-03-08) build.
When setting both speed and/or quality with a video played in full screen, the video remains in full screen after the setting is done.
Device used: Google Pixel 7 (Android 13).
Marking the ticket as verified fixed for 112.

This bug was a regression in 111, but I don't think it's critical enough to uplift to a 111 dot release. We have more critical fixes already planned for 111.0.1. We can reconsider for 111.0.2 after the fix has baked on Beta 112 for a week.

I don't think we need to uplift this fix to the next 111 dot release. This fix can ride the trains in 112.

:cpeterson if you and the team think a request is too risky, when setting the version to wontfix please also clear the uplift request.