Single Screen View for Opera

Single Screen View is a dependency-free Opera/Chromium extension that denies the standard Window Management API for one website tab at a time.

Install in Opera

1. Open opera://extensions.
2. Turn on Developer mode.
3. Choose Load unpacked and select this opera-single-screen folder.
4. Pin Single Screen View from Opera's extensions menu if desired.

Use it

Open an HTTP or HTTPS page, select the extension, and turn the rule on. Opera reloads that tab. Turn it off to remove the rule and reload again. Other tabs are untouched, and navigation in the same tab remains covered until the rule is removed, the tab is closed, or the browser session ends.

If Opera cannot reload after a successful rule change, the popup reports the live new state and asks you to reload manually. A rule can still be turned off after its tab navigates to an Opera-internal or otherwise unsupported URL.

How it works

The extension creates a session-scoped Declarative Net Request rule for the selected tab's main-frame response and appends:

Permissions-Policy: window-management=()

It never uses the set/replace operation. Appending a valid denial should preserve unrelated directives in a site's policy while restricting the standardized window-management feature. However, duplicate or malformed Permissions-Policy headers, browser parsing differences, and another extension modifying the same header require end-to-end validation in the target Opera build. The diagnostics page reports API readiness and configured rules only; it cannot prove that a particular network response was modified or parsed as intended.

Rule state is derived from the current session rules. Rules use a dedicated signature and allocated IDs, so cleanup removes only positively recognized rules belonging to this feature.

Local Opera validation target

Node.js is enough to run the included local target:

node manual/server.mjs

Open http://127.0.0.1:8765/plain. The page reports whether getScreenDetails() exists, displays screen.isExtended, and lets you call the API. For the strongest acceptance check, use a computer with at least two active displays: record the OFF screen.isExtended baseline, expect ON to report false, and expect OFF to restore the baseline. Allow Opera's window-management permission when testing the OFF baseline. The server also exposes:

• /preexisting-allow — sends window-management=*
• /unrelated — sends geolocation=()
• /malformed — sends a malformed policy value
• /duplicate — sends two Permissions-Policy header values

End-to-end checklist

• ON/OFF: On /plain, record the OFF screen.isExtended value, switch ON, confirm the page reloads, screen.isExtended becomes false, and the API call is denied. Switch OFF and confirm it reloads and restores the recorded value.
• Second tab isolation: Open two target tabs. Enable only the first; the first should show screen.isExtended = false and be denied while the second retains its OFF value and behavior.
• Navigation persistence: With a tab ON, navigate it from /plain to /unrelated. The popup should remain ON, screen.isExtended should remain false, and the Window Management call should remain denied.
• Tab-close cleanup: Enable one tab, open Diagnostics in another, and note the configured count. Close the enabled tab, refresh Diagnostics, and confirm the count drops without affecting other configured tabs.
• Preexisting allow: On /preexisting-allow, verify OFF follows the site's allow policy and ON still denies the Window Management call.
• Unrelated policy: On /unrelated, verify the unrelated directive remains present in Opera DevTools and ON denies only the Window Management capability.
• Malformed policy: Test /malformed ON and OFF and record Opera's actual parsing behavior; do not infer success from Diagnostics alone.
• Duplicate policy: Test /duplicate ON and OFF, inspect the response in Opera DevTools, and verify behavior in the exact Opera version being released.
• Other extensions: Repeat the matrix with other header-modifying/privacy extensions disabled and enabled; their rule ordering and header edits can change the final response.

If Opera does not expose getScreenDetails(), the extension can still configure its rule but this target cannot behaviorally verify the Window Management denial.

Automated tests

Run:

node tests/run-tests.mjs

Or run npm test. No package installation is needed. Tests cover rule construction, allocation, isolation, cleanup, API failures, and reload partial-success handling. They mock Chromium APIs; they do not replace the Opera checklist above.

Limits and privacy

• This does not merge, mirror, disable, or virtualize physical Windows displays.
• It only targets the standardized browser Window Management API controlled by the window-management Permissions Policy feature.
• It cannot defeat unrelated signals, custom fingerprinting, window dimensions, or adversarial/non-standard detection.
• Opera internal pages, New Tab, file URLs, and extension pages cannot receive the response header.
• Session rules end with the browser session.
• There are no analytics, accounts, external requests, or collected data. HTTP/HTTPS host access exists only so Opera can append the selected tab's response policy.