Improve fullscreen script to inject when PIP is triggered #56383

The YouTube PiP toolbar flow depends on a small script that puts the mobile YouTube player into fullscreen before Brave asks Android to enter PiP. That step is necessary because Android PiP captures the fullscreen video surface. The existing script is too dependent on one YouTube DOM shape and on timing events that are not stable during cold loads, slow networks, and YouTube player hydration.

When the user taps the toolbar PiP button, Brave should make the fullscreen request promptly if the player is ready, but it also needs to keep watching for the controls when YouTube has not rendered them yet. The improved script should use a deterministic sequence of attempts, resolve only once, avoid toggling fullscreen off when it is already active, and avoid racing two fullscreen mechanisms against each other.

Current issues

• It relies on a narrow set of selectors, so a YouTube player variant can fail even when the video and fullscreen control are present.
• It waits on canplay in a way that ties fullscreen entry to video decode readiness instead of the availability of the player control.
• It can miss the moment when YouTube inserts or reveals the fullscreen button after the script already ran.
• It may resolve too early with missing elements during a slow player load, leaving the toolbar PiP request with no fullscreen transition.
• It does not have a single shared completion guard, so multiple asynchronous paths can compete after the user has already moved on.
• It does not first check both document fullscreen and YouTube player fullscreen state, so fallback logic can accidentally call a toggle API from the wrong state.
• It does not have a broad enough fallback strategy for YouTube player variants where the visible button is delayed or unavailable.

Proposed change

• Replace the old entry script with a staged fullscreen algorithm inside kYoutubeFullscreen.
• Start immediately after DOMContentLoaded when needed, or immediately if the document is already ready.
• First detect whether the document or YouTube player is already fullscreen and return without toggling it back out.
• Try the fast path by clicking the YouTube fullscreen control when the video and control are already present.
• Tap the player once to reveal controls, then retry the fast path.
• Fall back to YouTube's own toggleFullscreen API only when the player is not already fullscreen.
• Fall back to the standard requestFullscreen API on the player, player container, or video element when no YouTube control path is available.
• Use a MutationObserver on the player subtree, or the document body as a last resort, so the script reacts as soon as YouTube inserts or reveals the fullscreen control.
• Keep a 30 second timeout so the observer cannot live forever on a broken or unexpected page.
• Resolve through a single resolveOnce function so late callbacks cannot report conflicting results.
• Keep the script in ISOLATED_WORLD_ID_BRAVE_INTERNAL and execute it with user activation, matching the existing Brave controlled injection model.

Expected result

• Tapping the toolbar PiP button should enter fullscreen quickly when YouTube is already ready.
• Cold cache loads and slow networks should still work once the player controls appear.
• YouTube player UI changes should be less likely to break PiP entry.
• The flow should avoid entering PiP with no fullscreen video content.
• Already fullscreen pages should not be toggled back out by the fallback path.
• The entry script should be a clearer, more maintainable sequence with explicit state checks and bounded async work.