<rdar://problem/102023484>

Still reproduces as of 2026 (WebKit iOS simulator; macOS can't exercise it since lock() there is NotSupportedError). Two distinct sub-behaviors, both off-spec: 1. Lock not released. Enter fullscreen, screen.orientation.lock("landscape") (opposite of current), then exitFullscreen(). screen.orientation.type stays landscape-primary / angle 90 after exit, and no change event fires. The lock is retained after leaving fullscreen. 2. Pending promise not aborted. If lock() is still pending when fullscreen exits, the promise resolves rather than rejecting with AbortError. Per the Fullscreen Standard's exit algorithm, exiting fullscreen runs Screen Orientation's "fully unlock the screen orientation steps", which should reject-and-nullify [[orientationPendingPromise]] with AbortError and apply a null lock (releasing it, so orientation reverts). WebKit runs neither part on fullscreen exit. No WPT currently covers either half (fullscreen-interactions.html tests other cases); worth adding one alongside a fix.

Clarification on point 2 above. As currently written, whether a *pending* lock() promise is rejected on fullscreen exit is not deterministic: "reject and nullify the current lock promise" queues a task to reject, and the lock's own resolution is likewise a queued task, with no defined ordering between them. So a UA could resolve (and nullify) the promise before the exit's reject step runs, which would make "resolves" defensible against the current text. The intent, however, is that exiting fullscreen MUST abort an in-flight lock() with AbortError. The Screen Orientation spec will be tightened to guarantee that ordering, after which resolving a still-pending lock on fullscreen exit is a conformance failure. So point 2 stands as a conformance target once that spec clarification lands. Point 1 (the active lock is retained after exit, orientation does not revert) is a bug today regardless of the above, since the fully-unlock steps apply a null lock to the top document unconditionally.