390243 - The cut and copy events can fire even when there has nothing been cutted or copied

Status: RESOLVED INVALID

(Core :: DOM: Events, defect)

Description

[Martijn Wargers (dead)]

See testcase.
When using 'cut' or 'copy' on the text controls when there is nothing selected in the text control, the  corresponding events still gets fired.
This is not what IE7 is doing. In IE7, it only fires when something in the text control is selected.

Comment 1

[Mathieu Fenniak]

Safari fires the cut/copy events even with a collapsed selection as well, but I agree that this is silly.  Taking.

Comment 2

[Mathieu Fenniak]

Attachment: patch

Attaching patch that checks for collapsed selection before firing cut & copy events in both editors and documents.

Comment 3

[Martijn Wargers (dead)]

Mathieu, you forgot to paste an email address in the review box.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

Does IE fire beforebut/copy events in this case?

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

And does the same thing happen with paste if there isn't anything 
to paste?

Comment 6

[Martijn Wargers (dead)]

(In reply to comment #4 and comment #5)
> Does IE fire beforebut/copy events in this case?
> And does the same thing happen with paste if there isn't anything to paste?

With the ctrl-C key and the context (and top edit menu) menu, beforecopy events are in IE7 always fired, even when nothing is selected.
With the ctrl-X key and the context (and top edit menu) menu, beforecut events are not fired when nothing is selected.
When there isn't anything to paste, the beforepaste event is still fired, but the paste event is not, when pressing the ctl-V key. The paste menu-item is disabled.

Comment 7

[Mathieu Fenniak]

IE basically fires the before event whenever the associated menu item appears, it seems, regardless of whether the selection is collapsed.  However, the menu items don't appear for document regions when the selection is collapsed, so the events aren't fired.

This causes a bit of inconsistency between edit regions (contentEditable, textarea, input) and document regions in IE, since edit regions always have the menu options (even when the selection is collapsed), and document regions only have all the menu items when a selection is made.  Hence whether the events are fired when selection is collapsed depends on whether you're in an edit region or a document region.

Comment 8

[Mathieu Fenniak]

IE does not fire the paste event when the clipboard is empty.  We do.  I think this should be fixed as well.

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 275126 [details] [diff] [review]
patch

So also firing paste event should be prevented.

Comment 10

[spam]

Don't know if this is the same issue bug the onbeforepaste event is also executed without any paste action.

Check the test page I made here:
http://tinymce.moxiecode.com/gecko/beforepaste.htm

I can create a new bug report for this if it's not the same issue.

Comment 11

[Mathieu Fenniak]

[e-mail]: the beforepaste event can be fired without any paste action, and this is by design.  The event is similar to IE "beforepaste" event, which is just a check to see if pasting is possible in the current context.  In IE, this event will occur when you pull down the "Edit" menu, for example, to see if the paste menu item should be enabled.

"beforepaste" is badly named.  Do not use it to anticipate a paste.  It just allows you to enable or disable pasting.

Comment 12

[spam]

Okey, didn't know that thanks for the info. But what I was trying to to with the beforepaste event was to some how trapping the pasted content.

The current Firefox implementation doesn't seem to have anyway of getting the actual contents like in IE or Safari. I like the Safari approach since it's more secure since you can only get the contents during a paste event.

This is how WebKit does it:
eventObj.clipboardData.getData('text/plain');

While in IE you can use:
window.clipboardData.getData('Text');

I know this is a bit of topic for this bug but, shouldn't it be a similar function in FF since both IE and WebKit has this functionality?

Comment 13

[Mathieu Fenniak]

Yeah, there probably should be.  But there isn't currently.  That could be the subject of a new bug, if you'd like to file it.

Comment 14

[Hallvord R. M. Steen [:hallvors]]

Per the clipboard events spec (which I'm editing) this bug was invalid. 

The reasoning is that a web app author may want to customize copy/cut behaviour even if there is no selection. For example, if you write a spreadsheet app you'll probably want to "fake" selectedness of specific cells - using native selection for this will probably look and feel odd - and customize ctrl-c and ctrl-x behaviour accordingly. So the most useful behaviour is that copy and cut event fire even if there is no selection.

(I think the behaviour has changed even though this bug is still open - so for example on http://dev.w3.org/2006/webapi/clipops/testsuite/002.html and http://dev.w3.org/2006/webapi/clipops/testsuite/003.html if you first delete the text, no events actually fire. No idea why this bug remains open if it is actually "fixed" - in any case I would like it "un-fixed" again for spec compliance and because I think that's a more useful behaviour.. Does everyone agree with closing this?)

Comment 15

[Mathieu Fenniak]

Hallvord: I'm comfortable with considering this bug invalid as you're suggesting.  The behaviour has never been well-defined by a spec before now, it's consistent with the specification you're authoring, and this behaviour has been available for nearly seven years so any change could be disruptive to current users.

Comment 16

[Olli Pettay [:smaug][[e-mail]]]

This bug is indeed old enough, and if we need fixes to follow the spec, better to file new bugs.

Comment 17

[Hallvord R. M. Steen [:hallvors]]

Closing this per general agreement - will report bugs on aligning with spec when I do a bigger test run later on.