Boris Zbarsky wrote: > Mike Perry wrote: >> While wading through the Firefox code, it appeared to me that event >> listeners were handled by most DOM objects via a >> nsEventListenerManager member instance. > > That's correct. > >> Specifically, it seemed to me >> that nsEventListenerManager::HandleEventSubType should be the codepath >> for javascript listeners, because it compiled the handler and then >> called out to nsJSEventListener::HandleEvent. > > In the case of addEventListener, aListener in this code is not an > nsIJSEventListener. It's an XPCWrappedJS implementing > nsIDOMEventListener. When the HandleEvent call happens, you end up in > nsXPCWrappedJSClass::CallMethod with the appropriate arguments.
Yeah, the problem here is that content listeners are added to the same place as listeners from chrome and extensions and other things that you do still want to work even when turning off "javascript". Note that much chrome code is implemented in javascript too, and you do off course not want to disable such listeners. >> If you are feeling particularly helpful, suggesting any other >> codepaths that might still allow Javascript to be executed after >> scripts have been disabled would be greatly appreciated as well. > > I commented on this to some extent in > <https://bugzilla.mozilla.org/show_bug.cgi?id=409737#c2>. In brief, > "lots of places, with more added every day as new DOM stuff appears". This is exactly what makes the bug really hard to fix. I think trying to fix this by not firing the listeners is too hard and error prone. Rather it needs to be fixed by detecting that we're about to execute a JS function that is implemented in a context where JS is turned off. Or some such. So later in the callchain. / Jonas _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
