- From: Hallvord Reiar Michaelsen Steen <hallvord@opera.com>
- Date: Fri, 02 Nov 2012 16:45:18 +0100
- To: olli@pettay.fi, "Glenn Maynard" <glenn@zewt.org>
- Cc: sebastian@calyptus.eu, "Bjoern Hoehrmann" <derhoermi@gmx.net>, "Daniel Cheng" <dcheng@chromium.org>, "Aryeh Gregor" <ayg@aryeh.name>, "Ryosuke Niwa" <rniwa@webkit.org>, "WebApps WG" <public-webapps@w3.org>, "Travis Leithead" <travis.leithead@microsoft.com>, "Ojan Vafai" <ojan@chromium.org>
It should work just fine if you check the whole eventtarget chain (from the target to the window object).
> But that means adding a capturing listener on the window would apply this affect
> to every single element on the page. If that's an acceptable result, then just
> add the menu item all the time and forget about the event handler logic.
It's not only about the context menu (which could be "scoped" to whatever element was targeted by a right-click), it's also about the "Edit" menu or the "inline" commands in Chrome's normal application menu. Enabling the menu entries all the time breaks with existing UI conventions. Even when using Opera's implementation, most pages do of course not add copy/cut/paste event listeners in the first place, so on most sites the menu is only enabled when there is a selection, the way users expect. And integrating well with what users expect from the native UI seems to be important for web apps. I believe that for example Google Docxs maintains a selection in a hidden IFRAME with editable content in order to manipulate the enabledness of copy/cut menu entries. This is of course a horrible hack and navigator.setCommandState('copy', true) would be much better.
--
Hallvord R. M. Steen
Core tester, Opera Software
Received on Friday, 2 November 2012 15:46:17 UTC