-
-
Notifications
You must be signed in to change notification settings - Fork 124
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use generic event listener for link processing #732
Comments
Jaifroid
changed the title
Use generic event listener for link processing in jQuery mode
Use generic event listener for link processing
Nov 21, 2021
As discussed at the Hackathon, we may be forced to apply some link processing in SW mode to enable opening external links in a new tab or window. The method outlined above (minimized for the single requirement of opening external links) could be used for this purpose. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is point 1 discussed in #725. Rather than a new feature for jQuery, I see it as code cleanup, and it will prevent seeing so many "violations" for adding non-passive event listeners to hundresds of document links that show up in the Chromium console. Instead, we add a single
onclick
event listener on the iframe's contentWindow. Then we use almost exactly the same code as we currently have to analyse the clicked link. So changes would be minor.It's the same solution as proposed for Option 2 of #404, except that of course for SW mode the function would only intervene if the user has clicked a link that navigates away from the document. The code for this could be re-used between both modes, or not used at all for SW mode if it is determined not to be safe.
I did bash together a prototype yesterday (it only took 15 minutes) as a quick test for how Option 2 of #404 would work, but if not used there, the same principle can be used for this PR. It is in branch Check-for-external-links-and-warn and only works in SW mode to check for external links and asks the user if they want to access the site. It can be used for testing the viability of #404, but also for testing the principle of this PR before writing any more code.
The text was updated successfully, but these errors were encountered: