What are the different concepts and techniques for sharing window position data between browser windows?

To detect the position of a window, you can use the window.screenX and window.screenY properties. These properties return the x and y coordinates of the window on the screen.

For example, you can log the position of the current window to the console:

console.log('Window position:', window.screenX, window.screenY);

This will output the x and y coordinates of the window in pixels.

In modern browsers, you can't directly track changes to the browser window's position on the screen due to security and privacy restrictions. However, there is a partial workaround using the window.screenX and window.screenY properties. These give you the x and y coordinates of the window relative to the user's screen.

You can monitor changes by polling these values at regular intervals. For example, you could use setInterval to check every 500 milliseconds whether the values have changed, and then react accordingly. That said, this only works reliably in popup windows or controlled browser environments. In normal browser tabs, these properties may return zero or be blocked entirely depending on the browser and the platform. Some browsers also limit access to this information altogether for security reasons.

If you're building something that needs to detect repositioning, consider whether you can achieve your goal another way — for instance, by monitoring viewport size, scroll behavior, or window focus/blur events. Let me know what you're trying to build, and I can help you find a more robust approach.

Here's a simple example of how you might implement this:

The window and screen objects in JavaScript offer several useful properties that can help you understand and respond to the browser window's behavior or environment—especially if you're working on something related to window positioning or resizing.

Useful window Properties

window.innerWidth / window.innerHeight

Returns the viewport size (the visible area inside the window, excluding toolbars and scrollbars). → Useful for responsive design or checking if the window is minimized or resized.

window.outerWidth / window.outerHeight

Gives the full size of the browser window, including borders and toolbars. → Helps detect the total window dimensions, including chrome.

window.screenX / window.screenY

Returns the position of the window relative to the screen. → Handy for limited window movement tracking.

window.devicePixelRatio

Indicates the pixel density (e.g., Retina displays have a ratio > 1). → Useful when working with graphics or high-DPI support.

window.screenLeft / window.screenTop

Similar to screenX / screenY, more relevant for compatibility with older browsers. → Be cautious — support is inconsistent.

Useful screen Properties

screen.width / screen.height

Returns the total screen resolution (e.g., 1920×1080). → Helps understand screen context or scale window sizes accordingly.

screen.availWidth / screen.availHeight

Gives the available screen size, excluding system UI like taskbars. → Useful for centering popups or maximizing windows within usable space.

The opener property allows a window to reference the window that opened it. This is useful for sharing data between windows. For example, if you have a main window that opens a new window, you can use the opener property to access the main window's properties and methods.

Window Opener Demo

The `postMessage` method allows you to send messages between windows. This is useful for sharing data between windows that are not related (i.e., they do not share the same opener).

Post Message Demo

The `localStorage` object allows you to store data in the browser. This is useful for sharing data between windows that are not related (i.e., they do not share the same opener). The data is **synchronous** and **string-based** (you store and retrieve strings only) and it doesn’t expire.

Local Storage Demo

The `SharedWorker` object allows you to create a worker that can be shared between multiple windows. This is useful for sharing data between windows that are not related (i.e., they do not share the same opener). The data is **asynchronous** and **string-based** and it doesn’t expire.

Shared Worker Demo

We can also use the SharedWorker for centralised state management.

Shared Worker with Central State Management Demo

In this article, we explored different concepts and techniques for sharing data between browser windows. We learned how to detect window position, observe window position changes, and use opener, postMessage, localStorage, and SharedWorker to share data between windows.

Comparison Table: Multi-Window Communication Techniques

Concept	Advantages	Disadvantages
Using window.opener	Direct reference to the parent window Easy to call functions or access properties directly	Only works for windows opened via window.open() No cross-tab support Easily breaks on reloads
Using postMessage	Works between parent and child Can pass messages across origins No shared memory needed	Only point-to-point (no broadcast) Requires explicit window reference No persistence
Using localStorage	Simple key-value storage Persistent across reloads storage event allows cross-tab updates	No structured data (strings only) No live two-way channel Not reactive in the same window
Using SharedWorker	Persistent background process Can coordinate multiple windows Reusable logic	More complex setup Limited browser support (e.g. no Incognito) No built-in state management
SharedWorker + Central State Management	Combines shared communication and shared logic Keeps global state in one place Fully decouples windows from each other	Requires custom implementation of state handling Harder to debug Not persistent across full browser shutdowns

When to Use What?

• Use window.opener for quick control between parent/child, but not for scalable systems.
• Use postMessage when direct but flexible messaging is needed.
• Use localStorage for persistent, simple key–value sync, with minimal effort.
• Use SharedWorker when you need live coordination across windows.
• Use SharedWorker + central state for real-time, stateful multi-window applications that require coordination, tracking, or shared logic.

This extended version of the SharedWorker-based Central State Management system now includes additional window-specific properties. In addition to tracking each window’s position, the system also observes its current size and automatically calculates its center point (midpoint). These values are stored centrally within the worker and kept up to date through regular updates. This provides a more complete spatial model of all active windows and allows for more precise coordination and layout logic across multiple browser views.

Multi-Window Worker Demo

• MDN Web Docs: Window.opener
• MDN Web Docs: Window.postMessage
• MDN Web Docs: LocalStorage
• MDN Web Docs: SharedWorker