I am building a web application that is for the virtual world. It has two windows, one to share in a meeting (View) and one to control the shared window (Control). My concept is the user would open the Control page and the Control page would open the View page (basically: <Body onload=window.open(“URL to view”, ‘_blank’>). The issue is pop-up blockers stop this because it is not base on user action. Right now I just have a button for the user to open the View, but that is not a good user experience. I also don’t want to ask people to disable pop-up blockers. Is there a way around this so the app can have two windows?
Creating new windows (or pop-ups) that are not a direct result of user interaction is generally frowned upon, both for user experience and security reasons. That’s why modern browsers block such attempts unless they’re initiated directly by a user action, like a click event.
Here are a few alternative approaches you could consider that align with typical browser security restrictions:
User-Initiated Action: Continue using a button, but make it more integrated into the user experience. For example, during the initial setup or tutorial phase of your application, instruct users to click the button to open the View window as part of the process.
Browser Extensions: A browser extension could be granted permission to open new windows without direct user interaction. This would require users to install your extension, but it provides a more seamless experience once set up.
Window Communication: If the user manually opens both the Control and View windows, you could use
Single Page Application (SPA): Design your application as a SPA where the Control and View are part of the same window but perhaps in different panes or tabs. You can use front-end frameworks like React, Vue, or Angular to make the user experience smooth and dynamic.
Client-side routing: Use a client-side router to switch between the Control and View within the same page. The router can control what’s displayed, giving the illusion of two separate pages without actually navigating away or opening a new window.
Secondary Device: Consider a design where the Control could be operated from a secondary device like a tablet or smartphone. This would require a responsive design that can adapt to various screen sizes.
WebSocket or Server-Sent Events: Have the Control window communicate with your server using WebSockets or Server-Sent Events, and then the server can push the necessary updates to the View window. This way, you could potentially open the View window manually and have it update in real time based on actions from the Control window.
Remember that no matter which route you choose, clear instructions and intuitive design will be key to ensuring a good user experience. It’s also important to respect the browser’s security model and user preferences, as these are in place to protect the user from unwanted behavior from websites.
Thanks for the detailed response. I think keeping the user action (i.e. button) is the only viable option in my case.
Have you considered the html5 dialog element?
I have a web app that if there is no filename in local storage when the page loads a file open dialog opens.
Thanks Dennisjn. I never heard of this approach, but it looks interesting. It might require a complete refactoring of the application but might me worth it. (i.e. the view page becomes primary and the control page becomes secondary) I might prototype it our fist to see if it will work for me.