1271897 - Cut-Copy-Paste are NOW broken, Episode 1 - Paste is disabled when file is copied to clipboard

Status: RESOLVED INVALID

(Core :: DOM: Events, defect, P5)

Description

[arni2033]

>>>   My Info:   Win7_64, Nightly 49, 32bit, ID 20160504043118
STR:
1. Open attachment 8666449 [details].
2. Right-click inside input on the page from Step 1.

AR:  "Cut", "copy" actions are available.
ER:  "Copy" should be available only if some text is selected, "cut" - if that text could be deleted.

This is regression between Firefox 40 and Firefox 44.

Comment 1

[magicp]

This is correct behavior.

Bug 1159490 - Allow cut/copy event dispatch unconditionally in HTML documents. r=neil

Regression range:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=dc683817edece10117f758c4274d5af3a2f57107&tochange=1921222e708e8b070b8ef5db215d5bec2217d375

Comment 3

[arni2033]

(In reply to magicp from comment #1)
> This is correct behavior.
That is such a relief to know that it's every other application and browser is broken, not Firefox :)

(In reply to Alice0775 White from comment #2)
> *** This bug has been marked as a duplicate of bug 1178047 ***
I think it's not a duplicate of bug 1178047, because:
(A) bug 1178047 was closed with words "Chrome does the same and nobody cares about this regression"
(B) context menu works differently than buttons in bug 1178047.
Well, Chrome doesn't do the same in this bug. And the whole thing (Firefox) is very buggy.
I have testcases that can make cut (and copy) button disabled, but corresponding menu items always end up enabled. I think it's possible to break menuitems as well, but I need to know exact logic of UI to describe breakages. Nobody really considered UI logic in bug 1159490, so I'm setting NI now.


@ Ehsan Akhgari (NI):
Hello, Ehsan! In bug 1178047 comment 9 you said that "This is intended". What is "this" exactly?
Please reveal what logic of menuitems in contextmenu you had in mind while working on bug 1159490 & co

Currently, menuitems "cut" and "copy" have no relation to the actual text editing (unlike any other Windows application I tested). But they also have no relation to "cut" and "copy" events as when I disable clipboard events via about:config, the menuitems still look active.
Browser is not a web page, and it must "know" more than a web page: cut/copy items should be disabled.

Even if we pretend that menuitems display which events could be applied, there's a remaining problem:
"paste" menuitem is disabled when I copy a file to clipboard and follow comment 0.
So connected menuitems (cut-copy-paste) serve different purposes: cut/copy are about events, and paste is about text editing. This UI inconsistency was brought by bug 1159490 & co.

In case you really had a plan to make an indication whether event could be applied, such attempts to educate end users (regular Joes Mozilla aiming at) about events seem very strange and useless, because in most cases there's no cut/copy listeners attached to the page. But anyway, menuitems should reflect the actual action, i.e. "apply cut event", "apply copy event", "paste text".

Finally, I have testcases disabling copy and cut buttons in HTML documents.
So I also expect some feedback on the issues listed above. In my opinion, bug 1159490 is about events, so you couldn't possibly _plan_ any change in UI, so this change is unintentional.

Comment 4

[magicp]

(In reply to arni2033 from comment #3)

> That is such a relief to know that it's every other application and browser
> is broken, not Firefox :)

> breakages. Nobody really considered UI logic in bug 1159490, so I'm setting
> NI now.

Okay! :)

Comment 5

[(no longer active)]

The reason why these menu items are always enabled is that HTML requires the browser to dispatch the cut, copy and paste events to the web page and the web page can choose to handle these events or ignore them.  Before dispatching the events it's impossible for the browser to know how the web page chooses to respond to these events, if it chooses to handle them at all, so we cannot determine whether these commands should be enabled like we used to (for example based on whether something has been selected for cut and copy.)

So if we kept the old behavior that you're asking for us to restore, we wouldn't be able to dispatch these events to the web page.  That's problematic for pages that want to do their own custom clipboard handling.  I wish we could come up with something better to do here, but it's not obvious to me what a better thing to do would be.

Note that at first glance it may appear that we could modify our behavior to only enable these commands when the web page installs an event handler for these clipboard events and disable them otherwise, but even that wouldn't be completely correct since just the presence of the event handler doesn't mean that the page will actually do something based on the event, since an event handler may choose to ignore an event.  If we did that we would change the problem to having these commands be enabled on some web pages, but not on others, and them sometimes doing something and other times not when they are enabled, which doesn't sound ideal.

The issue about the paste command is bug 1208217.  We should probably fix that bug sooner than later.

I hope the above explains the rationale for this change of behavior.  Contrary to what you are suggesting, the change was completely intentional.  I understand that you may not like this change, but it's still an intentional change that we made to the behavior of Firefox.

If you have any suggestions for a better strategy for handling this, please let us know!

Comment 6

[arni2033]

> HTML requires the browser to dispatch the cut, copy and paste events to the web page
It doesn't require cut-copy-paste menuitems in browser be about events. Menuitems don't_have_to be
always enabled; HTML only requires the browser to dispatch event when corresponding action happens.

> if we kept the old behavior that you're asking for us to restore,
> we wouldn't be able to dispatch these events to the web page
1) My comments may seem ambiguous, but I'm only asking for a logical behavior of context menu.
   There're 2 possible concepts - "menuitems as text editing commands" and "menuitems as events", but
   you end up with some mixed behavior in HTML documents. (I wonder if front-end team was aware)
2) It'll still be possible to dispatch those events if you stick with the first concept.

So, that intentional change had no real reason. At least you agreed that context menu is currently illogical ('paste' menuitem is inactive), therefore this bug is valid. Bug 1208217 changed nothing at
all, so I'd like to reopen this bug for "fixing" paste menuitem. I have no time, but can explain other
bugs (comment 3), or why "fixed" context menu will still operate wrong (via comment/email/irc/etc).

Comment 7

[Justin Dolske [:Dolske]]

(In reply to arni2033 from comment #6)
> > HTML requires the browser to dispatch the cut, copy and paste events to the web page
> It doesn't require cut-copy-paste menuitems in browser be about events.
> Menuitems don't_have_to be
> always enabled; HTML only requires the browser to dispatch event when
> corresponding action happens.

I think Ehsan's point here is that disabling these Firefox menuitems would prevent using them on pages using the HTML clipboard API/events. EG, if the page is listening for the "copy" event to provide some page-specific data, the browser has to leave the menuitem enabled all the time.

(This ultimately feels like a spec weakness, ideally there should be a way for the page to indicate when these commands are actually actionable?)


(In reply to :Ehsan Akhgari from comment #5)
[...]
> Note that at first glance it may appear that we could modify our behavior to
> only enable these commands when the web page installs an event handler for
> these clipboard events and disable them otherwise, but even that wouldn't be
> completely correct since just the presence of the event handler doesn't mean
> that the page will actually do something based on the event, since an event
> handler may choose to ignore an event.

This wouldn't be perfect, but would be an incremental improvement over the current situation. (No opinion on if the implementation cost/benefit is worth it.)


(In reply to arni2033 from comment #3)
> > This is correct behavior.
> That is such a relief to know that it's every other application and browser
> is broken, not Firefox :)

Chrome currently seems to behave the same way as Firefox -- the Cut/Copy/Paste UI elements are always enabled. Safari supports the API, but always leaves the UI elements disabled (so they're impossible to use). Neither Edge nor IE support the API yet (maybe they support something older though? Not sure.).

Comment 8

[Jet Villegas (inactive)]

Adding a dependency here to bug 1271897. I think an important step here is to write a (failing) test that can go in the tree.

Comment 9

[Jet Villegas (inactive)]

(In reply to Jet Villegas (:jet) from comment #8)
> Adding a dependency here to bug XXXXXXX. I think an important step here is
> to write a (failing) test that can go in the tree.

Correction: needs a test added to bug 1277113.

Comment 10

[Liz Henry (:lizzard) (relman/hg->git project)]

Sounds like having some failing tests is the first step here for issues like this where the behavior breaks often. But we can live with this for now in 49.

Comment 12

[arni2033]

Several bug reports were filed by other users; this bug report mentioning ~5 bugs was reported
7+ MONTHS AGO, and not a single finger was moved, what shows that Ehsan clearly has an intention to
make (and keep) Firefox UI as broken and illogical as possible, and the rest of the team approves it
(otherwise bug 1159490 would be backed out, since it doesn't improve anything (in fact, if there was a
slightest intention to fix/improve UI, bug 1159490 would be enabled for Nightly only from the start))

I had to file ALL 6 bugs I discovered 7 months ago, instead of ~3, because throughout 7+ months Ehsan Akhgari never changed his mind that Firefox UI should stay broken (and there were no fixes at all).

If it wasn't his intention, the new functionality would be tested at least 1-2 minutes before
pushing it to release and breaking UX, or fixed shortly after I filed the bug. Please don't edit
whiteboard (unless you have some _real_ info proving it wrong) as it provides useful information to
users, and explains that broken/illogical UI is intentional, i.e. there's no sense discussing it.


(In reply to Justin Dolske [:Dolske] from bug 1271897 comment 7)
> I think Ehsan's point here is that disabling these Firefox menuitems would prevent using them on
> pages using the HTML clipboard API/events. EG, if the page is listening for the "copy" event to
> provide some page-specific data, the browser has to leave the menuitem enabled all the time.
Could you please be constructive? Like use expression "Ehsan decided w/o asking anybody (else?) from UX team" instead of "the browser has to", "would prevent using them (but not another, more natural way of triggering clipboard event handlers, i.e. Ctrl+X/C/V)" instead of "would prevent using them".
It's hard to answer to your comment if you're hiding your (team's) intents behind such expressions.
There're also 2 things you're trying to ignore (what for?), please comment on them:
1) People in regression bug 1159490 agreed to implement a UX breakage (explained below)
2) Users don't think it's any good (explained below)

I only accept 4 goals as valid/logical options for UX, and I don't think you have any other ideas:
   i) To allow triggering event handlers via CCP from toolbarbutton/menu bar/context menu
  ii) To allow triggering event handlers via CCP from toolbarbutton/menu bar w/o breaking anyting else
 iii) To provide a good UI
  vi) To implement accessibility for triggering clipboard event handlers w/o breaking anything else

(vi) is already implemented, it seems, because Ctrl+X/C/V were available even before regression bug 1159490. And also (vi) so far is covered by (i) and (ii), so I think there's no sense in discussing it
(iii) is too unclear, I only mentioned it to stress out that that Mozilla doesn't aim at (iii):
to make a good UI one would need to consider all cases, to test possible UI before pushing it to Release, and possibly gather statistics. None of that was made in bug 1159490.
On the other side, (i) and (ii) are quite clear. (i) assumes that user should be able to always apply
CCP from toolbarbutton/menu bar/context menu, but currently context menu is inconsistent: sometimes it
shows "copy" menuitem, sometimes it doesn't. So (i) isn't fulfilled (Episode 6). (ii) isn't fulfilled
too, because "Copy" menuitem is enabled in context menu of <input> on page   data:text/html,<input>

1) You said "browser has to ...", so you (as a person) clearly think you (team) are aiming at (i).
   Even if it was true, you (team) failed at that (see Episode 6: user still can't apply "paste"
   event from context menu, because it's disabled/removed by browser).
   But it's not true, because in regression bug 1159490 you (team) implemented some random changes and
   never tested it, i.e. had no real plan, just like it always happens in Mozilla.
   Currently you're pretending that Ehsan's idea is almost working, justifying regression bug 1159490.
   That idea is nothing more than "add illogical behavior and figure out further steps after a year".
   Could you please agree on the fact that you (team) never thought through the plan/never tried to 
   test the UX part of bug 1159490, before making any point here?
   It would make the conversation constructive and removed all misunderstanding:
   conversation with someone who has a plan is different from discussing an incomplete functionality.
2) "disabling these Firefox menuitems would prevent using them on pages using the clipboard events"
   It doesn't look like users had any problems applying cut/copy/paste events before regression
   bug 1159490, they even filed several bugs for you asking to restore old way of enabling CCP
  (cut/copy/paste), because, unlike current illogical design, it provided some visual/mnemonic info.
   So once again, people in bug 1159490 intentionally implemented a thing that is bad for users.

(In reply to Justin Dolske [:Dolske] from bug 1271897 comment 7)
> Chrome currently seems to behave the same way as Firefox -- the
> Cut/Copy/Paste UI elements are always enabled.
First, you haven't even tested GoogleChrome. GoogleChrome matches expectations of comment 0 and
bug 1303033. Second, you rushed to make a point justifying invalid Firefox behavior using your
unchecked data. Like it always happens in Mozilla (see bug 1251977 comment 11, bug 1251977 comment 18,
bug 1251977 comment 21). So this arguement doesn't count.
Luckily, _I_ tested GoogleChrome 7 month ago, and I there's no difference in its behavior up until now
If anybody wants to read the accurate description, read "Cut-Copy-Paste are NOW broken, Episode 6"

Comment 15

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)

Comment 16

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

The original intention of this bug report is by design (comment 5). So I close this bug as INVA, feel free to file new bugs if you think some individual cases do not make sense to you.