Open Bug 299526 Opened 20 years ago Updated 3 years ago

Context menu not blocked on scrollbars when JS is turned off globally

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Type:
defect

Tracking

()

People

(Reporter: neil, Unassigned)

Details

(Keywords: regression)

Steps to reproduce problem: 1. Load a page with scrollbars (textarea, iframe or long page) 2. Enable JavaScript 3. Right-click on a scrollbar 4. Disable JavaScript 5. Right-click on a scrollbar Expected result: no context menus appear Actual result: context menu appears when JS is globally disabled Additional information: scrollcorner doesn't seem to block context menu at all.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050629 Firefox/1.0+ WFM
Could this be related to bug #228144?? Only if I could make sense of what the reporter meant about "Expected Results:" but I understood the "Actual Results:"..
So should the scrollbar block the event with a declarative <handler> rather than via script?
(In reply to comment #3) >So should the scrollbar block the event with a declarative <handler> rather >than via script? Except a) disabling scripts also disables declarative handlers b) we use the same <handler> for preventdefault (declarative) and preventBubble() (script).
> disabling scripts also disables declarative handlers Er... it does? I was under the impression that it did not (eg the middle-paste-on-scrollbar fix uses declarative handlers to work even when script is off). > and preventBubble() (script) There is no declarative way to preventBubble?
Well, nsXBLBinding::InstallEventHandlers() is pretty much wrapped inside an if (AllowScripts()) block. This has only been a problem since you beefed up AllowScripts() for bug 292591. There is no declarative equivalent to preventBubble(), but then if JS is disabled it doesn't really matter.
> Well, nsXBLBinding::InstallEventHandlers() is pretty much wrapped inside an if > (AllowScripts()) block. Hmm... So it is. Perhaps we should change that and do the AllowScripts() check in the handler execution itself before running any JS? But then I don't see why bug 301873 is fixed by the patches in it (or by the patch for bug 70698 on the trunk)...
Although it would work on 1.7.x it's still failing on trunk for me.
Ah, I see. For editor scrollbars we do it in the C++... Though at this point I'm confused. The scrollbar binding is a chrome binding, is it not? I'd pretty purposefully tried to not break those in bug 292591 -- see bug 292591 comment 18, last paragraph... I wonder what gives here.
And I can't reproduce this with current seamonkey trunk (either classic or modern theme). Should I look for a branch seamonkey build?
Sorry for jumping to conclusions earlier. This is a combination of disabling JavaScript (which prevents the preventBubble) and dom.event.contextmenu.enabled (which prevents the preventDefault).
But why is preventBubble prevented, given that this is a chrome binding?
Because nsScriptSecurityManager::CanExecuteScripts returns PR_FALSE.
(bindings execute with the principals of the bound, not binding, document)
If we could somehow make all xbl bindings on native anonymous content have the system principal then we could make scrollbars truly anonymous (which currently breaks because the constructor needs to access the element or something).
> Because nsScriptSecurityManager::CanExecuteScripts returns PR_FALSE. What's the caller of this method? Note that nsXBLBinding::AllowScripts uses the principal of the binding document for the check. So is this some other CanExecuteScripts check? I also question why that pref affects preventDefault. I agree that it should affect preventDefault for unprivileged script, but privileged content (eg chrome XBL as in this case) should be able to block the context menu no matter what the pref is set to. Perhaps we need a separate bug on that.
I don't know why that pref was implemented in the way that it was, but it means that calling preventDefault on a context menu event has no effect. From memory nsScriptSecurityManager::CanExecuteScripts is called from nsScriptSecurityManager::CheckFunctionAccess called from nsJSContext::CallEventHandler called from nsJSEventListener::HandleEvent called from nsXBLPrototypeHandler::ExecuteHandler called from nsXBLEventHandler::HandleEvent
> I don't know why that pref was implemented in the way that it was, but it means > that calling preventDefault on a context menu event has no effect. Right. I'm proposing we change that so it checks who the caller is, and have chrome XBL doing a declarative preventDefault push a null JSContext on the JS context stack, or something... > From memory nsScriptSecurityManager::CanExecuteScripts is > called from nsScriptSecurityManager::CheckFunctionAccess > called from nsJSContext::CallEventHandler Right. Not much we can do about that, I guess. :( Not without changing a lot of the arch of XBL.
(In reply to comment #18) >Right. I'm proposing we change that so it checks who the caller is, and have >chrome XBL doing a declarative preventDefault push a null JSContext on the JS >context stack, or something... I'm not sure what you mean by "it" here - I guess you'll need a new subclass of nsDOMEvent whose preventDefault method checks for content JS on the stack.
Whatever class it is whose preventDefault method at the moment checks that pref is "it". Before checking the pref, it would check who's calling.
The pref is currently checked for by the context menu event listener.
Er... you mean it just ignores the fact that the event was prevented? That sucks. A lot. :( Could we file a bug to fix it?
I suppose it would be too confusing to morph this one?
Hmm... I guess this bug doesn't cover anything else, eh? ;) Let's do it.
Assignee: events → nobody
QA Contact: ian → events
Component: Event Handling → User events and focus handling
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.