User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:188.8.131.52) Gecko/20071222 Remi/184.108.40.206-1 Firefox/220.127.116.11
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:18.104.22.168) Gecko/20071222 Remi/22.214.171.124-1 Firefox/126.96.36.199
Steps to Reproduce:
1. open about:config
2. Visit http://fscked.org/transient/firefoxjsbug.html
3. Click on the page
5. Click on the firefox bug page again. Observe that some event handlers have been disabled, others have not
While some types of event listeners are blocked, other event listeners still fire.
Have you considered adapting the "session restore" functionality and simply closing existing pages, then resurrecting the user's state when they turn off the Tor button? Even if you kill off the remaining event listeners for existing pages I'd still be nervous about letting Tor users interact with them.
What we could probably do is make AutoScriptEvaluate::StartEvaluating return an error if script can't be executed on that cx with the relevant principal. That somewhat relies on the right cx being used, but we certainly do that with the cx pusher for event listeners.
Unfortunately, other callbacks into JS may not be so lucky (XMLHttpRequest readystate handlers come to mind, though there could also be issues in any DOM API that allows passing in page-implemented callbacks and might call them async... Or even that doesn't return for a long time (e.g. one of the callbacks does sync XMLHttpRequests or some such). With this last, for example, treewalker's nodefilters could be attacked. Or the namespace resolver from the proposed DOM API for Selectors. Or any of a number of other callbacks. I guess in the long-running situation the calling cx will still be on the stack, so things might be ok and we only need to worry about propagating the right cx into async callbacks...
That would only affect the docshell setting and per-site settings, though. If we fail to get the right cx but are really async, we'll get the safe context and that's affected by the general "turn off JS" pref. So at least as a first approximation doing the checks in StartEvaluating would work.
That said, nsXPCWrappedJSClass::CallQueryInterfaceOnJSObject does an OBJ_GET_PROPERTY before calling StartEvaluating. That doesn't seem safe... brendan, am I missing something there?
Requesting blocking, but I'm not completely sure it should, to be honest...
Not blocking as this is how we've always behaved and it's late in the release cycle. But wanted as it would be nice to have if someone came up with a safe fix.
BZ or Jonas, do you have anyone in mind who could work on this?
Smaug might be a good candidate.
any news during the last few years?
It's a pretty low priority. I suspect that in the end someone who actually cares about dynamically enabling/disabling JS while a site is live will need to step up and fix this. I'm happy to point to relevant code as needed.
I've filed a separate bug for this, but it might be better included in this bug. I hope someone will fix it, because it greatly impacts major features of the <editor> element, including image drag and drop.
Yeah, that's different from this bug, since comment 0 explicitly says that attribute on* handlers _are_ prevented in the case this bug is filed about.
It seems that jsdIStackFrame.executionContext.scriptsEnabled may also be a victim.
We added this code to Firebug 1.5:
context.eventSuppressor = context.window.getInterface(Ci.nsIDOMWindowUtils);
in addition to
executionContext.scriptsEnabled = false;
when we stop on a breakpoint.
This immediately solved one bug and we've not seen bad side effects. The only funny business was puzzing: if we call context.window.getInterface() after returning from the debuggers nested event loop, it fails. That is why we save the interface ref in context.eventSuppressor so we can use that to free the window after we return.
(In reply to comment #15)
> We added this code to Firebug 1.5:
> context.eventSuppressor = context.window.getInterface(Ci.nsIDOMWindowUtils);
> if (context.eventSuppressor)
John, I've tried doing this call on the contentWindow attribute of the relevant tabbrowser.docShell attribute, but it is disabling all hotkeys in the entire browser window. For example, control-t will not cause that browser window to open a new tab if the tab itself is the currently selected widget (as opposed to the URL bar, for example).
Did you notice this side effect as well? If not, which window are you actually calling suppressEventHandling on?
(In reply to comment #16)
> ...but it is disabling all hotkeys in the entire
> browser window.
> Did you notice this side effect as well?
(Not that this is related to this bug, but) preventing all hotkeys if the focused windows has events suppressed is by design, not a side effect.
Mike, mozilla.dev.platform is a great place to ask such questions. And I'll confirm what Olli said as what we also see.
My apologies. I was just trying to keep some historical record for other people who hit this bug and try the workaround, since it is going on 3 years old, and I've long since lost any hope for an actual fix :)
I will try to investigate more and if needed continue workaround discussion somewhere else...
Status needs to be changed to Confirmed.
Not blocking 1.9.3 on this bug.
The Tor Project / Electronic Frontier Foundation is paying to have this bug fixed.
"If you know C++ and/or Firefox internals, we should be able to pay you for your time to address these issues and shepherd the relevant patches through Mozilla's review process."
The original test case no longer works. But if it did we could see if Firebug 1.7 can block the events. I guess yes, we use nsIDOMWindowUtils suppressEventHandling(true).
Created attachment 651688 [details]
Since the original test case has disappeared, I took the liberty of making a new one.
*** Bug 812056 has been marked as a duplicate of this bug. ***
*** Bug 652049 has been marked as a duplicate of this bug. ***
Fixed by bug 862627.