fix: Enable orientation lock and improve webview fullscreen handling

[HarishV14]

• Set lockToLandscape = true on WebViewFragment inside FermionLiveStreamFragment to trigger landscape rotation when entering fullscreen mode.
• Prevent setting webView visibility to GONE in CustomWebChromeClient during onShowCustomView to avoid premature Chromium custom view teardown.
• Guard updateLayoutForOrientation in FermionLiveStreamFragment when isFullScreen() is active to prevent window inset changes from interrupting fullscreen playback.
• Expose isFullScreen() in WebViewFragment to check WebChromeClient state.

[claude]

Claude finished @HarishV14's task in 3m 8s —— View job

---

Claude finished reviewing

Todo list

• Gather context (read changed files, diff)
• Understand the request (code review of PR fix: Enable orientation lock and improve webview fullscreen handling #1171)
• Review WebViewFragment.kt changes
• Review CustomWebChromeClient.kt changes
• Review FermionLiveStreamFragment.kt changes
• Post final review feedback

Summary

This PR fixes a real fullscreen-teardown bug in the WebView (previously the underlying webView was hidden via visibility = GONE, which some Chromium versions treat as a signal to prematurely tear down the fullscreen custom view) and adds an orientation-lock option for the Fermion live stream. Overall the approach is sound, and one change I want to call out positively: swapping customViewCallback?.onCustomViewHidden() for onHideCustomView() in the back-press handler (CustomWebChromeClient.kt:184) is a good fix — previously, pressing back while fullscreen relied on Chromium calling back into onHideCustomView() to actually restore orientation/system UI and clear customView/backCallback; if that didn't happen the fullscreen view/leak would persist. Calling onHideCustomView() directly guarantees cleanup while still notifying Chromium via the callback it invokes internally.

However, I found one crash risk worth fixing before merge.

Findings

🔴 Potential crash: isFullScreen() can be called before webView is initialized

core/src/main/java/in/testpress/fragments/WebViewFragment.kt:46-48

fun isFullScreen(): Boolean {
    return (webView.webChromeClient as? CustomWebChromeClient)?.isFullScreen() == true
}

webView is a lateinit var that's only assigned in onViewCreated() (WebViewFragment.kt:69). FermionLiveStreamFragment.updateLayoutForOrientation() calls webViewFragment?.isFullScreen() (FermionLiveStreamFragment.kt:261), and webViewFragment is assigned in loadInWebViewFragment() (FermionLiveStreamFragment.kt:123) right before the child-fragment transaction is committed (commitAllowingStateLoss()), which is asynchronous — the new WebViewFragment's onViewCreated() won't have run yet.

Concretely, when TestpressSdk.getTestpressSession(...) returns null, fetchSsoUrlAndLoad() calls loadInWebViewFragment() synchronously (FermionLiveStreamFragment.kt:78-80), so by the time updateLayoutForOrientation() runs on the next line in onViewCreated() (FermionLiveStreamFragment.kt:56), webViewFragment is non-null but its webView has not been initialized yet. Calling isFullScreen() will throw kotlin.UninitializedPropertyAccessException: lateinit property webView has not been initialized. The same race is theoretically possible on onConfigurationChanged if a rotation happens right after a fragment replace and before the child fragment's view is attached.

Suggested fix — guard against the uninitialized property:

fun isFullScreen(): Boolean {
    if (!::webView.isInitialized) return false
    return (webView.webChromeClient as? CustomWebChromeClient)?.isFullScreen() == true
}

Fix this →

Other observations (minor, non-blocking)

• course/src/main/java/in/testpress/course/fragments/FermionLiveStreamFragment.kt:131 — lockToLandscape = true is now hardcoded for all Fermion streams. This looks intentional for this feature, but it removes any future flexibility to opt out per-institute/config; just flagging in case that's a concern.
• No tests were added for the new isFullScreen() guard/orientation-lock behavior. Given this is UI/fragment-lifecycle logic, instrumented tests are likely impractical here, but if there's an existing instrumentation test suite for FermionLiveStreamFragment or WebViewFragment, it'd be worth extending it.
• core/src/main/java/in/testpress/util/webview/CustomWebChromeClient.kt:172-179 — removing fragment.webView.visibility = View.GONE/= View.VISIBLE is consistent with the stated goal (avoiding premature teardown); since the custom fullscreen view fully covers the decor view, leaving the underlying WebView visible-but-covered underneath is a reasonable tradeoff and shouldn't cause visible glitches.

No security, threading, or architecture concerns beyond the above — the change set is small and focused.
(branch)