940182 - Cut, Copy and Paste button in PanelUI do not work

Status: RESOLVED FIXED

(Firefox :: Toolbars and Customization, defect)

Description

[Alice0775 White]

Build Identifier:
http://hg.mozilla.org/mozilla-central/rev/f2adb62d07eb
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 ID:20131118094134

Steps To Reproduce:
Click "hamburger" button and click "Cut", "Copy" and "Paste" button

Actual Results
Nothing happens

5. Click hamburger and click "Copy" button
6. Attempt to paste to other application
 
Actual Results
Nothing happens or previous clipped text is pasted

7. Copy any text with Ctrl+C
8. Put caret on input field
9. Click hamburger and click "Paste" button

Actual Results
Nothing happens

Comment 1

[Alice0775 White]

Oops, sorry.
please ignore following. 

> 5. Click hamburger and click "Copy" button
> 6. Attempt to paste to other application
> 
> Actual Results
> Nothing happens or previous clipped text is pasted
> 
> 7. Copy any text with Ctrl+C
> 8. Put caret on input field
> 9. Click hamburger and click "Paste" button
> 
> Actual Results
> Nothing happens

Comment 2

[dusty-2011]

(In reply to Alice0775 White from comment #1)
> Oops, sorry.
> please ignore following. 
> 
> > 5. Click hamburger and click "Copy" button
> > 6. Attempt to paste to other application
> > 
> > Actual Results
> > Nothing happens or previous clipped text is pasted
> > 
> > 7. Copy any text with Ctrl+C
> > 8. Put caret on input field
> > 9. Click hamburger and click "Paste" button
> > 
> > Actual Results
> > Nothing happens

Why should we ignore that? Is that working now for you?

So what exactly isn't working now for you? Can you be a bit clearer about that. If you try to copy text in an input field within the browser with the copy button, and then paste it in the same input field with the paste button, does'nt that work for you?

Comment 3

[Alice0775 White]

sorry,


"Cut", "Copy" and "Paste" does not work.

Copy selected text in web page/locationbar/searchbar: does not work
Paste to input/textarea in web page/locationbar/searchbar/findbar: does not work
Cut selected text in input/textarea of web page/locationbar/searchba/findbarr: does not work

"Cut", "Copy" and "Paste" are completely broken.

Comment 4

[Mike Conley (:mconley) (:⚙️)]

Yeah, I think we need some investigation here.

Comment 5

[Jim Jeffery not reading bug-mail 1/2/11]

STR:
1. Highlight any text, say from comment 4 above
2. Click the Menu-panel button and click 'copy'
3. Click the text-input box 
4. Click the Menu-panel button and click 'paste' 
5. Nothing is pasted.  

Repeat above steps instead of using 'copy' try 'cut' and steps 3-4, nothing is cut/pasted

No errors that I see in the error console.

Comment 7

[:Gijs (he/him)]

I'm sure this used to work on older Australis (UX) nightlies.

Comment 8

[:Gijs (he/him)]

(In reply to :Gijs Kruitbosch from comment #7)
> I'm sure this used to work on older Australis (UX) nightlies.

Huh. Except now I've gone back to July nightlies and still don't see it working. Jared, do you know if/when this was still working? Did it never work? :|

Comment 9

[Jared Wein [:jaws] (please needinfo? me)]

I spent the past hour playing with this and it worked intermittently. When it didn't work, I noticed that goDoCommand in globalOverlay.js was never entered when hitting the Paste button in the toolbar. However goSetCommandEnabled was entered with aID="cmd_paste" and aEnabled=true. Maybe there is something with focus changes causing the Paste action to not occur?

Comment 10

[:Gijs (he/him)]

So this is because I gave these buttons tabindex="0" in bug 881937. Taking that out makes them magically work again. I'm guessing because now when you click them they get focus, and we get confused about where the selection is (for cut/copy) or where focus was (for paste).

Neil, do you know a way to workaround this? Would closing (display:none-ing) the buttons be enough to convince copy/paste to work reliably?

Comment 11

[Neil Deakin]

> So this is because I gave these buttons tabindex="0" in bug 881937. Taking
> that out makes them magically work again. I'm guessing because now when you
> click them they get focus, and we get confused about where the selection is
> (for cut/copy) or where focus was (for paste).

It doesn't get confused no. The clipboard commands operate on the focused element. Since you've moved it to the button, there's nothing to operate on. And you won't know unless you keep track of where it was before.

I think you should back out bug 881937 which is my opinion is quite wrong.

That said, you could also implement and add a controller to the buttons or the window, but since you no longer know where the focus was before, I don't think you really would have any simple way to get this to work.

Comment 12

[:Gijs (he/him)]

(In reply to Neil Deakin from comment #11)
> I think you should back out bug 881937 which is my opinion is quite wrong.

Why? If we shouldn't be setting tabindex on toolbarbuttons, how else would we make keyboard access work?

Or, put another way, how come I can keyboard-navigate through a menu and hit copy there, and have it work? Do menus not actually have focus?

Comment 13

[:Gijs (he/him)]

(and, why is this a problem on Windows but not on OS X?)

Comment 14

[Neil Deakin]

(In reply to :Gijs Kruitbosch from comment #12)
> (In reply to Neil Deakin from comment #11)
> > I think you should back out bug 881937 which is my opinion is quite wrong.
> 
> Why? If we shouldn't be setting tabindex on toolbarbuttons, how else would
> we make keyboard access work?

You can already use the clipboard commands using the normal shortcut keys or by using the menu.

> Or, put another way, how come I can keyboard-navigate through a menu and hit
> copy there, and have it work? Do menus not actually have focus?

Menus don't change the focus. You could do something similar and implement your own key navigation for the panel though. You would need a capturing key listener added to the document and fire suitable accessibility events at the right time. That's quite a bit of work though.

Comment 15

[Neil Deakin]

(In reply to :Gijs Kruitbosch from comment #13)
> (and, why is this a problem on Windows but not on OS X?)

I doubt it works on Mac either. A mouse user might not notice it though as buttons don't get focused when clicked on Mac.

Comment 16

[:Gijs (he/him)]

(In reply to Neil Deakin from comment #14)
> (In reply to :Gijs Kruitbosch from comment #12)
> > (In reply to Neil Deakin from comment #11)
> > > I think you should back out bug 881937 which is my opinion is quite wrong.
> > 
> > Why? If we shouldn't be setting tabindex on toolbarbuttons, how else would
> > we make keyboard access work?
> 
> You can already use the clipboard commands using the normal shortcut keys or
> by using the menu.

To clarify, I meant "within the panel".

> > Or, put another way, how come I can keyboard-navigate through a menu and hit
> > copy there, and have it work? Do menus not actually have focus?
> 
> Menus don't change the focus. You could do something similar and implement
> your own key navigation for the panel though. You would need a capturing key
> listener added to the document and fire suitable accessibility events at the
> right time. That's quite a bit of work though.

Is there any documentation on which events these are?

Comment 17

[:Gijs (he/him)]

Attachment: fix Australis' cut/copy/paste buttons,

So I don't want to throw the baby out with the bathwater, and I've kept the tab indices for everything else to leave the remainder of the menu keyboard-accessible. If we want to do synthetic keyboard focus and all that, we should do it in a followup, IMO, but I'm hesitant to chuck out something that otherwise works. Let me know if you do want me to back everything out.

Comment 18

[:Gijs (he/him)]

remote:   https://hg.mozilla.org/integration/fx-team/rev/dc10b8966344

Comment 19

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/dc10b8966344

Comment 20

[Dão Gottwald [:dao]]

(In reply to :Gijs Kruitbosch from comment #17)
> So I don't want to throw the baby out with the bathwater, and I've kept the
> tab indices for everything else to leave the remainder of the menu
> keyboard-accessible. If we want to do synthetic keyboard focus and all that,
> we should do it in a followup

Filed bug 946297.