Refactor event handler
ferndot opened this issue · comments
For performance and security, we should get rid of the global event listeners in firetext.js.
@twiss and I discussed this on Gitter and propose that we create a new interface.js script that will manually add event listeners to interface elements. The script will pass events to the processActions function. Variables can be defined in the markup (e.g. data-click-location), but actions would be hard coded into the script.
Feel free to suggest modifications to this strategy.
I'm curious, why global event listeners shall be a perf and security issue.
Have you something to read for me?
The security issue arises from our definition of the actions in the markup. E.g. data-click="nav" data-click-location="add". It is basically a sneaky way of doing eval().
Also, intercepting all click, submit, keypress, mousedown, focus, blur, or gesture events across the entire app has to hurt performance.
(@joshua-s beat me to it :))
Delegated event handlers can in some cases be faster, because having many event handlers is slow and having one event handler (on the parent of those elements, say) is faster. However, if you put a delegated event handler on document (or html, or body) you have to check whether you're interested in the event every time the user does anything anywhere, which can be slow. I don't know if this is the case for us, though. More info and "proof": http://stackoverflow.com/a/8827535.
Re. security, normally, if you put a user's html in the dom without escaping or thoroughly sanitizing it (https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet), you have an XSS vulnerabilty (the user can run any script he wants). CSP can mitigate this by disallowing things like onclick="foo()", <script>foo()</script> and more. However, we implement data-click="bar" where bar is defined in processActions, which is not as bad but still bad.
@twiss I think that we would want to incur the CPU usage on listener creation. That way, we can get the brunt of it out of the way during the app's load stage and leave the app performant for interactions. It may not be a big deal on desktop, but I am sure that it will impact mobile.
Yep, I agree, I only meant that testing is better than theory, in other words, does it feel sluggish on some phones. However, the security reason alone is enough to do this, so no need to test this now IMO.
Thank you for the information!