- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 02 May 2012 09:57:58 -0400
- To: public-webapps@w3.org
On 5/2/12 2:23 AM, Aryeh Gregor wrote: > For the former, I'd suggest onbeforecontextmenu, with some way to > disable specific options I would think that disabling cut/copy/paste would apply to main menus too, not just context menus. Most people I know who use menus for this (which is precious few, btw, for the most part people I know seem to use keyboard shortcuts for cut/copy/paste) use the main menu, not the context menu... One question is whether this use case (which I agree seems worth addressing) requires a new event. That is, is it better for the browser to fire events every time a menu is opened, or is it better for apps that want to maintain state like this to update some property on the editable area whenever their state changes and for browsers to just read those properties when opening a menu? The latter is, from my point of view as a browser implementor, somewhat simpler to deal with, since it doesn't involve having to worry about alert() or sync XHR or window.close() in menu-opening code. But I can see that it might be more complicated to author against... -Boris
Received on Wednesday, 2 May 2012 13:58:33 UTC