Extend popover support to new tabs or windows

[Jaifroid]

Once #1252 is finished, it might be a good idea to extend popover support to new windows and tabs opened by the app.

This is a bigger job, hence would need to be a separate PR. Up till now, we have not attempted to keep any reference to new containers, and so we can't track them in order to add the necessary event listeners. This is done in the PWA, but there is quite a lot of infrastructure associated with it there. It might be possible to do a "light" version here.

For info, tabs and windows are navigable in ServiceWorker mode, because the SW deals with the page's Fetch requests. But the SW doesn't have any access to the DOM, so cannot process links to add popovers.

[tinkerer-shubh]

Hii, I would like to work on this issue.

[Jaifroid]

@tinkerer-shubh Please read CONTRIBUTING in this Repo very carefully, and try to set up, and then come back here and explain your proposed solution to this issue.

[tinkerer-shubh]

@Jaifroid Thank you so much! I really appreciate your guidance and would love your input as I move forward with this.

Here’s my proposed approach for extending popover support to new windows and tabs:
-Use postMessage: This will allow the main window to communicate with new tabs or windows, so popovers can be initialized as soon as a new one opens.
-Embed an initialization script: Include a script in the new windows or containers to make sure popovers are enabled, either as a fallback or as the main method.
-Consider BroadcastChannel (optional): If real-time synchronization of popovers across multiple windows or tabs is needed, explore using BroadcastChannel to keep everything in sync.

I’d love to hear your thoughts on this plan and whether you’d recommend starting with a specific step.

[Jaifroid]

@tinkerer-shubh Thanks for your thoughts. I don't think either suggested method is the first thing to try. There may be a simpler fix. We will only be opening new tabs or windows in Same Origin, so we can communicate with those windows. For new tabs/windows currently the main method of communication is that the Service Worker intercepts their Fetch requests and then asks app.js for the requested content. It already maintains an open channel between itself and app.js.

However, the tricky thing here is that there is no way to tell if a hyperlink is being hovered unless an event listener is attached to it or to a parent. Since we try hard not to alter DOM content, the solution has been to add an event listener to the iframe window/document. But when we open a new window, we no longer place content in an iframe: it is placed directly in the window. Therefore, once the initial content has loaded in that window, we will need to attach an event listener to the window or the window's document so that it will fire when a link is hovered or tabbed into.

Currently, the popover interceptor is added here, straight after the content is loaded in the new iframe. That code currently only runs if there's an iframe. The trick will be to see if you can make it run when the content is not in an iframe but in a separate window or tab. Then you'll need to debug other places in the code where an iframe is assumed. The idea would be to generalize the attaching code as much as possible. It may be possible to use defaultView to achieve this in a generalizable way, or that may not be necessary if the variable iframeArticleContent contains a usable window/document when we're not actually accessing content in an iframe. This needs testing in Dev Tools in your browser.