-
Notifications
You must be signed in to change notification settings - Fork 27
Description
Is your feature request related to a problem? Please describe.
Currently, the spec allows the host to inform the UI about its current display mode via hostContext.displayMode in the ui/initialize result, and the host can notify the UI of changes via ui/host-context-change. However, there is no mechanism for the UI (iframe) to request a display mode change from the host.
This creates a limitation for interactive applications that may want to:
- Request fullscreen mode when entering an immersive experience
- Request picture-in-picture (PiP) mode for video playback
- Request to exit fullscreen and return to inline mode
- Transition between display modes based on user interaction within the app
Describe the solution you'd like
Add a new UI-to-host JSON-RPC method that allows the UI to request a display mode change. For example:
// New method: ui/request-display-mode
interface RequestDisplayModeParams {
displayMode: "inline" | "fullscreen" | "pip" | "carousel";
}
interface RequestDisplayModeResult {
success: boolean;
currentDisplayMode: string; // The actual mode after the request
}The host would still have full control over whether to honor the request, maintaining the security model where the host is the ultimate authority over its shell/embedding.
Describe alternatives you've considered
-
Using
ui/messagefor display mode requests: The UI could send a custom message viaui/messagerequesting a mode change, but this requires non-standard handling and isn't part of the formal protocol. -
Relying solely on host-initiated changes: Apps could include UI elements that hint to users to use host controls (e.g., "Click the fullscreen button in the toolbar"), but this provides a poor user experience.
Additional context
This feature would enable richer interactive applications while preserving the host's authority over display decisions. The host can always deny requests based on its policies, user preferences, or platform constraints.