1. Create a page with the following HTML: <html> <body onbeforepaste="alert('onbeforepaste fired!');" contenteditable="true"> </body> </html> 2. Open it on IE. 3. Open the context menu on it by either right-cliking on the page or by using the context menu button of the keyboard.
Wow. Confirmed with Safari/WebKit 5.1.3 and with ToT.
Is this comment in Editor.cpp no longer true? // WinIE uses onbeforecut and onbeforepaste to enables the cut and paste menu items. They // also send onbeforecopy, apparently for symmetry, but it doesn't affect the menu items. // We need to use onbeforecopy as a real menu enabler because we allow elements that are not // normally selectable to implement copy/paste (like divs, or a document body). bool Editor::canDHTMLCut() { return !m_frame->selection()->isInPasswordField() && !dispatchCPPEvent(eventNames().beforecutEvent, ClipboardNumb); } bool Editor::canDHTMLCopy() { return !m_frame->selection()->isInPasswordField() && !dispatchCPPEvent(eventNames().beforecopyEvent, ClipboardNumb); } bool Editor::canDHTMLPaste() { return !dispatchCPPEvent(eventNames().beforepasteEvent, ClipboardNumb); } bool Editor::canCut() const { return canCopy() && canDelete(); }
I don't get it. Isn't this the behavior that's expected?
See also: bug 34894.
*** This bug has been marked as a duplicate of bug 34894 ***
(In reply to comment #3) > I don't get it. Isn't this the behavior that's expected? It depends on the "onbeforeX" event definition. As many onbefore events, I expect it to be very related to their relative "on" events. For example, while "oncut" is fired as soon as "cut" is executed (after its effects), I expect "onbefurecut" to happen right *before* the cut effects takes place. Using it as a menu item enabler is totally unexpected and if an event system is really needed for that, better to come with a different event name for it, otherwise we would need to have an "onbefore" event for every single possible menu option, which is senseless. Of course, you guys can always inject a new definition for the before events on HTML5 specs just to match your current behavior, but this would sound definitely weird.
> Using it as a menu item enabler is totally unexpected and if an event system is really needed for that, better to come with a different event name for it, otherwise we would need to have an "onbefore" event for every single possible menu option, which is senseless. The quoted comment implies that we're just matching Internet Explorer (what it actually does, not what MSDN says). Given that they invented this event, it seems right to emulate IE. However maybe this comment is not 100% accurate?
(In reply to comment #7) > > Using it as a menu item enabler is totally unexpected and if an event system is really needed for that, better to come with a different event name for it, otherwise we would need to have an "onbefore" event for every single possible menu option, which is senseless. > > The quoted comment implies that we're just matching Internet Explorer (what it actually does, not what MSDN says). Given that they invented this event, it seems right to emulate IE. However maybe this comment is not 100% accurate? IE9 still fires beforepaste event on opening context menu. However, WebKit doesn't seem to fire beforepaste when we actually paste :(
> However, WebKit doesn't seem to fire beforepaste when we actually paste :( If that's the difference, let's close bug 34894 as invalid, and file a new one. This is all quite confusing, so repurposing the bug would be harmful.
(In reply to comment #9) > > However, WebKit doesn't seem to fire beforepaste when we actually paste :( > > If that's the difference, let's close bug 34894 as invalid, and file a new one. This is all quite confusing, so repurposing the bug would be harmful. That sounds reasonable to me. I'm also going to give a feedback on public-webapps about this.