Re: Re: Re: [Clipboard API] The before* events
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. But that's the point: if you do this, then a page adding a capturing listener on window or document will cause all of these things to happen up for every element on the page, because a capturing listener might affect anything. It's the same problem see if an event handler is registered-type solutions always cause. Glenn, I think we both fully understand the way this works and fails - the UI quirks and why they happen. Do you have any further thoughts on the navigator.setCommandState() proposal? Would this be better somewhere else in the API (some new execCommand() argument, perhaps?)? Do you think we loose anything if we don't spec before* events? (Sorry about any mangled quoting of previous messages - using a work webmail and I don't really trust its formatting..) -- Hallvord R. M. Steen Core tester, Opera Software
Re: Re: Re: [Clipboard API] The before* events
On Mon, Nov 5, 2012 at 8:49 AM, Hallvord Reiar Michaelsen Steen
hallv...@opera.com wrote:
Glenn, I think we both fully understand the way this works and fails -
the UI quirks and why they happen. Do you have any further thoughts on the
navigator.setCommandState() proposal? Would this be better somewhere else
in the API (some new execCommand() argument, perhaps?)? Do you think we
loose anything if we don't spec before* events?
Hallvord, that wasn't clear to me from the discussion, and I also wanted to
make sure that anyone following along understands why inspecting the event
chain like this for anything non-transparent (like optimization) has
problems.
These events do work for me in IE9. See
https://zewt.org/~glenn/test-with-onbefore.html and
https://zewt.org/~glenn/test-without-onbefore.html. Right-clicking the
image or the text in with enables cut and paste, which are greyed out in
without.
The events are fired in Chrome, but don't appear to do anything; cut and
paste never show up in the context menu at all.
I'm not quite sure why Opera needs to know whether elements have a listener
for this event. According to MSDN and my testing in IE9, merely attaching
a listener to these events does nothing; you have to cancel the event in
order to have any effect (eg. enabling menu items).
I don't think events are a good approach to this problem, and this only
seems to be functionally implemented in a single browser (IE), so I'd
recommend not specifying these events.
Another problem with using before* event to control the state of
copy/cut/paste UI is that it only works for UI that is shown/hidden on
demand (like menus) and not for UI that is always present (like toolbar
buttons). I'm not aware of web browsers that have UI with copy/cut/paste
buttons by default, but some browsers are customizable and some might have
toolbar buttons for this.
It seems to work for toolbars. It just means you'd need to fire these
events whenever focus changes, instead of only when a menu is opened.
That's ugly, but I'm not sure that it would actually cause obvious problems
(though it may cause unobvious web-compatibility ones).
However, enumerating every cuttable item on the page would mean firing an
event on every single element, which would probably cause trouble. For
example, a possible alternative UI would be a cut button which then
highlights all cuttable items on screen, allowing the user to click on
which one he wants to cut, or to drag a box around a bunch of items and cut
them all.
I'm wondering if specifying something like
navigator.setCommandState('copy', false); // any copy UI is now disabled
until app calls setCommandState('copy', true) or user navigates away from
page
This gives no way to allow clipboard operations for elements that don't
receive focus, such as allowing cut on an image. It also doesn't let you
find out if a particular element wants to allow copying, other than
focusing it and waiting to see if setCommandState is called, which might
not happen synchronously.
I think the right solution is attributes; for example,
div id=my-editable-box enable-clipboard=cut copy paste
which enables the selected operations for the element and its children. (I
don't know if it's useful to be able to undo this in children; that would
make it a bit more complicated.) This allows finding out whether an
element wants clipboard operations without any scripting side-effects, and
easily enumerating cuttable elements.
I don't know if this would actually want to be its own attribute, or if
there's an existing attribute that this can be added to. I don't think
enable-clipboard is actually a good name.
--
Glenn Maynard
Re: [Clipboard API] The before* events
On 11/02/2012 12:56 AM, Glenn Maynard wrote: On Thu, Nov 1, 2012 at 5:14 PM, Hallvord Reiar Michaelsen Steen hallv...@opera.com mailto:hallv...@opera.com wrote: The most IMHO elegant solution is what we implemented in Opera: we simply keep relevant menu entries enabled if there are event listeners registered for the corresponding event. This sort of goes against the registering event listeners should not have side effects rule, but it's a UI effect the page can't detect so I guess it's ok. This doesn't really work when pages put their event listeners further up the tree, eg. capturing listeners on the document and other event delegation tricks, right? It should work just fine if you check the whole eventtarget chain (from the target to the window object). -Olli -- Glenn Maynard
Re: Re: [Clipboard API] The before* events
On Thu, Nov 1, 2012 at 5:14 PM, Hallvord Reiar Michaelsen Steen hallv...@opera.com wrote: The most IMHO elegant solution is what we implemented in Opera: we simply keep relevant menu entries enabled if there are event listeners registered for the corresponding event. This sort of goes against the registering event listeners should not have side effects rule, but it's a UI effect the page can't detect so I guess it's ok. This doesn't really work when pages put their event listeners further up the tree, eg. capturing listeners on the document and other event delegation tricks, right? Why not? The UA can tell if there are copy/cut/paste listeners registered anywhere in the document. Besides, we have no way to tell whether the author's styling is implementing some faux object focus stuff, so we don't know where the user thinks the focus is. -- Hallvord R. M. Steen Core tester, Opera Software
Re: [Clipboard API] The before* events
On Fri, Nov 2, 2012 at 3:06 AM, Olli Pettay olli.pet...@helsinki.fi wrote: 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. On Fri, Nov 2, 2012 at 3:12 AM, Hallvord Reiar Michaelsen Steen hallv...@opera.com wrote: Why not? The UA can tell if there are copy/cut/paste listeners registered anywhere in the document. Besides, we have no way to tell whether the author's styling is implementing some faux object focus stuff, so we don't know where the user thinks the focus is. Because if you're trying to use the existance of event handlers to enable menu items on the correct elements, there's no way of knowing which element a capturing event handler higher up the tree is actually for. Or, for that matter, if it's for anything at all. A diagnostic library adding lots of capturing event handlers to the window for logging purposes shouldn't cause unexpected side-effects, like causing new menu items to show up. -- Glenn Maynard
Re: Re: [Clipboard API] The before* events
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
Re: Re: [Clipboard API] The before* events
On Fri, Nov 2, 2012 at 10:45 AM, Hallvord Reiar Michaelsen Steen hallv...@opera.com wrote: 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. But that's the point: if you do this, then a page adding a capturing listener on window or document will cause all of these things to happen up for every element on the page, because a capturing listener might affect anything. It's the same problem see if an event handler is registered-type solutions always cause. -- Glenn Maynard
RE: [Clipboard API] The before* events
I'm looking at the beforecut, beforecopy and beforepaste events. I don't
entirely understand their intent, it seems even more obscure than I expected..
I'm not sure that the use case that these events were originally designed for
(which have been obscured by time), are at all relevant to site content any
more. The use case of hiding the cut/copy/paste menu options, can be fulfilled
by replacing the contextmenu with some custom one if desired.
From: o...@google.com [mailto:o...@google.com] On Behalf Of Ojan Vafai
Sent: Wednesday, October 31, 2012 10:21 PM
To: Hallvord R. M. Steen
Cc: WebApps WG; Ryosuke Niwa; Aryeh Gregor; Daniel Cheng; Bjoern Hoehrmann;
Sebastian Markbåge
Subject: Re: [Clipboard API] The before* events
On Tue, Oct 30, 2012 at 9:42 AM, Hallvord R. M. Steen
hallv...@opera.commailto:hallv...@opera.com wrote:
I'm looking at the beforecut, beforecopy and beforepaste events. I don't
entirely understand their intent, it seems even more obscure than I expected..
Nothing in the official MSDN documentation [1] really explains the interaction
between beforecopy and copy (given that you can control the data put on the
clipboard from the copy event without handling beforecopy at all, the demo
labelled this example uses the onbeforecopy event to customize copy behavior
doesn't really make sense to me either.)
I was under the impression that you could handle the before* events to control
the state of copy/cut/paste UI like menu entries. However, when tweaking a
local copy of the MSDN code sample [2], I don't see any difference in IE8's UI
whether the event.returnValue is set to true or false in the beforecopy
listener.
Another problem with using before* event to control the state of copy/cut/paste
UI is that it only works for UI that is shown/hidden on demand (like menus) and
not for UI that is always present (like toolbar buttons). I'm not aware of web
browsers that have UI with copy/cut/paste buttons by default, but some browsers
are customizable and some might have toolbar buttons for this.
I'm wondering if specifying something like
navigator.setCommandState('copy', false); // any copy UI is now disabled
until app calls setCommandState('copy', true) or user navigates away from page
would be more usable? A site/app could call that at will depending on its
internal state. Or, if we want to handle the data type stuff, we could say
navigator.setCommandState('paste', true, {types:['text/plain','text/html']});
to enable any paste plain text and paste rich text UI in the browser?
I don't have a strong opinion on the specifics of the API, but I agree that
this is much more usable than the before* events. In the common case, web
developers would have to listen to selectionchange/focus/blur events and call
these methods appropriately.
The downside to an approach like this is that web developers can easily screw
up and leave the cut/copy/paste items permanently enabled/disabled for that
tab. I don't have a suggestion that avoids this though. I suppose you could
have this state automatically get reset on every focus change. Then it would be
on the developer to make sure to set it correctly. That's annoying in a
different way though.
-Hallvord
[1] http://msdn.microsoft.com/en-us/library/ms536901(VS.85).aspx
[2]
http://samples.msdn.microsoft.com/workshop/samples/author/dhtml/refs/onbeforecopyEX.htm
Re: [Clipboard API] The before* events
On Thu, Nov 1, 2012 at 4:02 AM, Travis Leithead
travis.leith...@microsoft.com wrote:
I'm looking at the beforecut, beforecopy and beforepaste events. I
don't entirely understand their intent, it seems even more obscure than I
expected..
** **
I’m not sure that the use case that these events were originally designed
for (which have been obscured by time), are at all relevant to site content
any more. The use case of hiding the cut/copy/paste menu options, can be
fulfilled by replacing the contextmenu with some custom one if desired.
You don't want to disable the other items in the context menu though. This
also doesn't solve disabling cut/copy/paste in non-context menus, e.g.
Chrome has these in the Chrome menu.
** **
*From:* o...@google.com [mailto:o...@google.com] *On Behalf Of *Ojan Vafai
*Sent:* Wednesday, October 31, 2012 10:21 PM
*To:* Hallvord R. M. Steen
*Cc:* WebApps WG; Ryosuke Niwa; Aryeh Gregor; Daniel Cheng; Bjoern
Hoehrmann; Sebastian Markbåge
*Subject:* Re: [Clipboard API] The before* events
** **
On Tue, Oct 30, 2012 at 9:42 AM, Hallvord R. M. Steen hallv...@opera.com
wrote:
I'm looking at the beforecut, beforecopy and beforepaste events. I don't
entirely understand their intent, it seems even more obscure than I
expected..
Nothing in the official MSDN documentation [1] really explains the
interaction between beforecopy and copy (given that you can control the
data put on the clipboard from the copy event without handling beforecopy
at all, the demo labelled this example uses the onbeforecopy event to
customize copy behavior doesn't really make sense to me either.)
I was under the impression that you could handle the before* events to
control the state of copy/cut/paste UI like menu entries. However, when
tweaking a local copy of the MSDN code sample [2], I don't see any
difference in IE8's UI whether the event.returnValue is set to true or
false in the beforecopy listener.
Another problem with using before* event to control the state of
copy/cut/paste UI is that it only works for UI that is shown/hidden on
demand (like menus) and not for UI that is always present (like toolbar
buttons). I'm not aware of web browsers that have UI with copy/cut/paste
buttons by default, but some browsers are customizable and some might have
toolbar buttons for this.
I'm wondering if specifying something like
navigator.setCommandState('copy', false); // any copy UI is now disabled
until app calls setCommandState('copy', true) or user navigates away from
page
would be more usable? A site/app could call that at will depending on its
internal state. Or, if we want to handle the data type stuff, we could say
navigator.setCommandState('paste', true,
{types:['text/plain','text/html']});
to enable any paste plain text and paste rich text UI in the browser?*
***
** **
I don't have a strong opinion on the specifics of the API, but I agree
that this is much more usable than the before* events. In the common case,
web developers would have to listen to selectionchange/focus/blur events
and call these methods appropriately.
** **
The downside to an approach like this is that web developers can easily
screw up and leave the cut/copy/paste items permanently enabled/disabled
for that tab. I don't have a suggestion that avoids this though. I suppose
you could have this state automatically get reset on every focus change.
Then it would be on the developer to make sure to set it correctly. That's
annoying in a different way though.
-Hallvord
[1] http://msdn.microsoft.com/en-us/library/ms536901(VS.85).aspx
[2]
http://samples.msdn.microsoft.com/workshop/samples/author/dhtml/refs/onbeforecopyEX.htm
** **
RE: [Clipboard API] The before* events
You are right, that it doesn't solve the disabling the option in the browser
chrome case-but is that really necessary? Why would a site want to do this?
The only reason I can imagine is the old we want to prevent the casual user
from copying this image because it is copyrighted scenario. In the cut/paste
interaction, there are other ways to handle this such as making the control
read-only, or stoping the action at the keyboard event level.
IE10 (and other UAs) have another solution-allow more fine-grained control over
the management of selection (css
propertyhttp://msdn.microsoft.com/en-us/library/ie/hh781492(v=vs.85).aspx,
and example usagehttp://ie.microsoft.com/testdrive/HTML5/msUserSelect/). I
can imagine a similar model for specific control over cut/copy/paste from
certain parts of the page if this is a hard requirement. The CSS property means
that the developer's request can be honored by the user agent without script
getting in the way of (and possibly delaying) the action.
From: o...@google.com [mailto:o...@google.com] On Behalf Of Ojan Vafai
Sent: Thursday, November 1, 2012 4:38 PM
To: Travis Leithead
Cc: Hallvord R. M. Steen; WebApps WG; Ryosuke Niwa; Aryeh Gregor; Daniel Cheng;
Bjoern Hoehrmann; Sebastian Markbåge
Subject: Re: [Clipboard API] The before* events
On Thu, Nov 1, 2012 at 4:02 AM, Travis Leithead
travis.leith...@microsoft.commailto:travis.leith...@microsoft.com wrote:
I'm looking at the beforecut, beforecopy and beforepaste events. I don't
entirely understand their intent, it seems even more obscure than I expected..
I'm not sure that the use case that these events were originally designed for
(which have been obscured by time), are at all relevant to site content any
more. The use case of hiding the cut/copy/paste menu options, can be fulfilled
by replacing the contextmenu with some custom one if desired.
You don't want to disable the other items in the context menu though. This also
doesn't solve disabling cut/copy/paste in non-context menus, e.g. Chrome has
these in the Chrome menu.
From: o...@google.commailto:o...@google.com
[mailto:o...@google.commailto:o...@google.com] On Behalf Of Ojan Vafai
Sent: Wednesday, October 31, 2012 10:21 PM
To: Hallvord R. M. Steen
Cc: WebApps WG; Ryosuke Niwa; Aryeh Gregor; Daniel Cheng; Bjoern Hoehrmann;
Sebastian Markbåge
Subject: Re: [Clipboard API] The before* events
On Tue, Oct 30, 2012 at 9:42 AM, Hallvord R. M. Steen
hallv...@opera.commailto:hallv...@opera.com wrote:
I'm looking at the beforecut, beforecopy and beforepaste events. I don't
entirely understand their intent, it seems even more obscure than I expected..
Nothing in the official MSDN documentation [1] really explains the interaction
between beforecopy and copy (given that you can control the data put on the
clipboard from the copy event without handling beforecopy at all, the demo
labelled this example uses the onbeforecopy event to customize copy behavior
doesn't really make sense to me either.)
I was under the impression that you could handle the before* events to control
the state of copy/cut/paste UI like menu entries. However, when tweaking a
local copy of the MSDN code sample [2], I don't see any difference in IE8's UI
whether the event.returnValue is set to true or false in the beforecopy
listener.
Another problem with using before* event to control the state of copy/cut/paste
UI is that it only works for UI that is shown/hidden on demand (like menus) and
not for UI that is always present (like toolbar buttons). I'm not aware of web
browsers that have UI with copy/cut/paste buttons by default, but some browsers
are customizable and some might have toolbar buttons for this.
I'm wondering if specifying something like
navigator.setCommandState('copy', false); // any copy UI is now disabled
until app calls setCommandState('copy', true) or user navigates away from page
would be more usable? A site/app could call that at will depending on its
internal state. Or, if we want to handle the data type stuff, we could say
navigator.setCommandState('paste', true, {types:['text/plain','text/html']});
to enable any paste plain text and paste rich text UI in the browser?
I don't have a strong opinion on the specifics of the API, but I agree that
this is much more usable than the before* events. In the common case, web
developers would have to listen to selectionchange/focus/blur events and call
these methods appropriately.
The downside to an approach like this is that web developers can easily screw
up and leave the cut/copy/paste items permanently enabled/disabled for that
tab. I don't have a suggestion that avoids this though. I suppose you could
have this state automatically get reset on every focus change. Then it would be
on the developer to make sure to set it correctly. That's annoying in a
different way though.
-Hallvord
[1] http://msdn.microsoft.com/en-us/library/ms536901(VS.85).aspx
[2]
http
Re: [Clipboard API] The before* events
I agree that this use case is not very important and possibly one we
shouldn't bother trying to solve. Hallvord's initial point, I think is that
there's really no use case for the before* events. We should kill them.
*If* we want to meet the use case those events purported to meet (not
displaying cut/copy/paste in menus), we should design a better API. It
sounds like noone especially cares for that use case though. I don't hear
web developers clamoring for it.
On Thu, Nov 1, 2012 at 11:12 AM, Travis Leithead
travis.leith...@microsoft.com wrote:
You are right, that it doesn’t solve the “disabling the option in the
browser chrome” case—but is that really necessary? Why would a site want to
do this?
** **
The only reason I can imagine is the old “we want to prevent the casual
user from copying this image because it is copyrighted” scenario. In the
cut/paste interaction, there are other ways to handle this such as making
the control read-only, or stoping the action at the keyboard event level.*
***
** **
IE10 (and other UAs) have another solution—allow more fine-grained control
over the management of selection (css
propertyhttp://msdn.microsoft.com/en-us/library/ie/hh781492(v=vs.85).aspx,
and example usage http://ie.microsoft.com/testdrive/HTML5/msUserSelect/).
I can imagine a similar model for specific control over cut/copy/paste from
certain parts of the page if this is a hard requirement. The CSS property
means that the developer’s request can be honored by the user agent without
script getting in the way of (and possibly delaying) the action.
** **
*From:* o...@google.com [mailto:o...@google.com] *On Behalf Of *Ojan Vafai
*Sent:* Thursday, November 1, 2012 4:38 PM
*To:* Travis Leithead
*Cc:* Hallvord R. M. Steen; WebApps WG; Ryosuke Niwa; Aryeh Gregor;
Daniel Cheng; Bjoern Hoehrmann; Sebastian Markbåge
*Subject:* Re: [Clipboard API] The before* events
** **
On Thu, Nov 1, 2012 at 4:02 AM, Travis Leithead
travis.leith...@microsoft.com wrote:
I'm looking at the beforecut, beforecopy and beforepaste events. I
don't entirely understand their intent, it seems even more obscure than I
expected..
I’m not sure that the use case that these events were originally designed
for (which have been obscured by time), are at all relevant to site content
any more. The use case of hiding the cut/copy/paste menu options, can be
fulfilled by replacing the contextmenu with some custom one if desired.***
*
** **
You don't want to disable the other items in the context menu though. This
also doesn't solve disabling cut/copy/paste in non-context menus, e.g.
Chrome has these in the Chrome menu.
*From:* o...@google.com [mailto:o...@google.com] *On Behalf Of *Ojan Vafai
*Sent:* Wednesday, October 31, 2012 10:21 PM
*To:* Hallvord R. M. Steen
*Cc:* WebApps WG; Ryosuke Niwa; Aryeh Gregor; Daniel Cheng; Bjoern
Hoehrmann; Sebastian Markbåge
*Subject:* Re: [Clipboard API] The before* events
On Tue, Oct 30, 2012 at 9:42 AM, Hallvord R. M. Steen hallv...@opera.com
wrote:
I'm looking at the beforecut, beforecopy and beforepaste events. I don't
entirely understand their intent, it seems even more obscure than I
expected..
Nothing in the official MSDN documentation [1] really explains the
interaction between beforecopy and copy (given that you can control the
data put on the clipboard from the copy event without handling beforecopy
at all, the demo labelled this example uses the onbeforecopy event to
customize copy behavior doesn't really make sense to me either.)
I was under the impression that you could handle the before* events to
control the state of copy/cut/paste UI like menu entries. However, when
tweaking a local copy of the MSDN code sample [2], I don't see any
difference in IE8's UI whether the event.returnValue is set to true or
false in the beforecopy listener.
Another problem with using before* event to control the state of
copy/cut/paste UI is that it only works for UI that is shown/hidden on
demand (like menus) and not for UI that is always present (like toolbar
buttons). I'm not aware of web browsers that have UI with copy/cut/paste
buttons by default, but some browsers are customizable and some might have
toolbar buttons for this.
I'm wondering if specifying something like
navigator.setCommandState('copy', false); // any copy UI is now disabled
until app calls setCommandState('copy', true) or user navigates away from
page
would be more usable? A site/app could call that at will depending on its
internal state. Or, if we want to handle the data type stuff, we could say
navigator.setCommandState('paste', true,
{types:['text/plain','text/html']});
to enable any paste plain text and paste rich text UI in the browser?*
***
I don't have a strong opinion on the specifics of the API, but I agree
that this is much more usable than the before
Re: [Clipboard API] The before* events
Den 1. nov. 2012 kl. 19:38 skrev Ojan Vafai o...@chromium.org: I agree that this use case is not very important and possibly one we shouldn't bother trying to solve. Hallvord's initial point, I think is that there's really no use case for the before* events. We should kill them. Makes it easier to ship my spec if we get a general agreement on this, so I won't exactly object to it :-) The potentially important part of the use case here is however not about *dis*abling copy/cut/paste menus. It is useful to be able to *en*able them when they would otherwise be disabled, say when there is no selection but the app/script fakes a selection of some entity or object it wants to let the user copy. The most IMHO elegant solution is what we implemented in Opera: we simply keep relevant menu entries enabled if there are event listeners registered for the corresponding event. This sort of goes against the registering event listeners should not have side effects rule, but it's a UI effect the page can't detect so I guess it's ok. It might not be a solution we can put in the spec though.. So do we want to handle this use case or ignore it for now? *If* we want to meet the use case those events purported to meet (not displaying cut/copy/paste in menus), we should design a better API. It sounds like noone especially cares for that use case though. I don't hear web developers clamoring for it. On Thu, Nov 1, 2012 at 11:12 AM, Travis Leithead travis.leith...@microsoft.com wrote: You are right, that it doesn’t solve the “disabling the option in the browser chrome” case—but is that really necessary? Why would a site want to do this? The only reason I can imagine is the old “we want to prevent the casual user from copying this image because it is copyrighted” scenario. In the cut/paste interaction, there are other ways to handle this such as making the control read-only, or stoping the action at the keyboard event level. IE10 (and other UAs) have another solution—allow more fine-grained control over the management of selection (css property, and example usage). I can imagine a similar model for specific control over cut/copy/paste from certain parts of the page if this is a hard requirement. The CSS property means that the developer’s request can be honored by the user agent without script getting in the way of (and possibly delaying) the action. From: o...@google.com [mailto:o...@google.com] On Behalf Of Ojan Vafai Sent: Thursday, November 1, 2012 4:38 PM To: Travis Leithead Cc: Hallvord R. M. Steen; WebApps WG; Ryosuke Niwa; Aryeh Gregor; Daniel Cheng; Bjoern Hoehrmann; Sebastian MarkbÃ¥ge Subject: Re: [Clipboard API] The before* events On Thu, Nov 1, 2012 at 4:02 AM, Travis Leithead travis.leith...@microsoft.com wrote: I'm looking at the beforecut, beforecopy and beforepaste events. I don't entirely understand their intent, it seems even more obscure than I expected.. I’m not sure that the use case that these events were originally designed for (which have been obscured by time), are at all relevant to site content any more. The use case of hiding the cut/copy/paste menu options, can be fulfilled by replacing the contextmenu with some custom one if desired. You don't want to disable the other items in the context menu though. This also doesn't solve disabling cut/copy/paste in non-context menus, e.g. Chrome has these in the Chrome menu. From: o...@google.com [mailto:o...@google.com] On Behalf Of Ojan Vafai Sent: Wednesday, October 31, 2012 10:21 PM To: Hallvord R. M. Steen Cc: WebApps WG; Ryosuke Niwa; Aryeh Gregor; Daniel Cheng; Bjoern Hoehrmann; Sebastian MarkbÃ¥ge Subject: Re: [Clipboard API] The before* events On Tue, Oct 30, 2012 at 9:42 AM, Hallvord R. M. Steen hallv...@opera.com wrote: I'm looking at the beforecut, beforecopy and beforepaste events. I don't entirely understand their intent, it seems even more obscure than I expected.. Nothing in the official MSDN documentation [1] really explains the interaction between beforecopy and copy (given that you can control the data put on the clipboard from the copy event without handling beforecopy at all, the demo labelled this example uses the onbeforecopy event to customize copy behavior doesn't really make sense to me either.) I was under the impression that you could handle the before* events to control the state of copy/cut/paste UI like menu entries. However, when tweaking a local copy of the MSDN code sample [2], I don't see any difference in IE8's UI whether the event.returnValue is set to true or false in the beforecopy listener. Another problem with using before* event to control the state of copy/cut/paste UI is that it only works for UI that is shown/hidden on demand (like menus) and not for UI that is always present (like toolbar buttons). I'm not aware of web
Re: [Clipboard API] The before* events
On Thu, Nov 1, 2012 at 5:14 PM, Hallvord Reiar Michaelsen Steen hallv...@opera.com wrote: The most IMHO elegant solution is what we implemented in Opera: we simply keep relevant menu entries enabled if there are event listeners registered for the corresponding event. This sort of goes against the registering event listeners should not have side effects rule, but it's a UI effect the page can't detect so I guess it's ok. This doesn't really work when pages put their event listeners further up the tree, eg. capturing listeners on the document and other event delegation tricks, right? -- Glenn Maynard
Re: [Clipboard API] The before* events
On Tue, Oct 30, 2012 at 9:42 AM, Hallvord R. M. Steen hallv...@opera.comwrote:
I'm looking at the beforecut, beforecopy and beforepaste events. I don't
entirely understand their intent, it seems even more obscure than I
expected..
Nothing in the official MSDN documentation [1] really explains the
interaction between beforecopy and copy (given that you can control the
data put on the clipboard from the copy event without handling beforecopy
at all, the demo labelled this example uses the onbeforecopy event to
customize copy behavior doesn't really make sense to me either.)
I was under the impression that you could handle the before* events to
control the state of copy/cut/paste UI like menu entries. However, when
tweaking a local copy of the MSDN code sample [2], I don't see any
difference in IE8's UI whether the event.returnValue is set to true or
false in the beforecopy listener.
Another problem with using before* event to control the state of
copy/cut/paste UI is that it only works for UI that is shown/hidden on
demand (like menus) and not for UI that is always present (like toolbar
buttons). I'm not aware of web browsers that have UI with copy/cut/paste
buttons by default, but some browsers are customizable and some might have
toolbar buttons for this.
I'm wondering if specifying something like
navigator.setCommandState('**copy', false); // any copy UI is now
disabled until app calls setCommandState('copy', true) or user navigates
away from page
would be more usable? A site/app could call that at will depending on its
internal state. Or, if we want to handle the data type stuff, we could say
navigator.setCommandState('**paste', true, {types:['text/plain','text/**
html']});
to enable any paste plain text and paste rich text UI in the browser?
I don't have a strong opinion on the specifics of the API, but I agree that
this is much more usable than the before* events. In the common case, web
developers would have to listen to selectionchange/focus/blur events and
call these methods appropriately.
The downside to an approach like this is that web developers can easily
screw up and leave the cut/copy/paste items permanently enabled/disabled
for that tab. I don't have a suggestion that avoids this though. I suppose
you could have this state automatically get reset on every focus change.
Then it would be on the developer to make sure to set it correctly. That's
annoying in a different way though.
-Hallvord
[1]
http://msdn.microsoft.com/en-**us/library/ms536901(VS.85).**aspxhttp://msdn.microsoft.com/en-us/library/ms536901(VS.85).aspx
[2] http://samples.msdn.microsoft.**com/workshop/samples/author/**
dhtml/refs/onbeforecopyEX.htmhttp://samples.msdn.microsoft.com/workshop/samples/author/dhtml/refs/onbeforecopyEX.htm
