Closed Bug 940182 Opened 7 years ago Closed 7 years ago

Cut, Copy and Paste button in PanelUI do not work

Categories

(Firefox :: Toolbars and Customization, defect)

28 Branch
x86_64
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 28

People

(Reporter: alice0775, Assigned: Gijs)

References

(Blocks 1 open bug)

Details

(Keywords: regression, Whiteboard: [Australis:P2])

Attachments

(1 file)

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
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
(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?
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.
Yeah, I think we need some investigation here.
Whiteboard: [Australis:M?][Australis:P3]
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.
Duplicate of this bug: 945034
Whiteboard: [Australis:M?][Australis:P3] → [Australis:M?][Australis:P2]
I'm sure this used to work on older Australis (UX) nightlies.
(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? :|
Flags: needinfo?(jaws)
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?
Flags: needinfo?(jaws)
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?
Flags: needinfo?(enndeakin)
> 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.
Flags: needinfo?(enndeakin)
(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?
Flags: needinfo?(enndeakin)
(and, why is this a problem on Windows but not on OS X?)
(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.
Flags: needinfo?(enndeakin)
(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.
(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?
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.
Attachment #8341854 - Flags: review?(jaws)
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Attachment #8341854 - Flags: review?(jaws) → review+
remote:   https://hg.mozilla.org/integration/fx-team/rev/dc10b8966344
Whiteboard: [Australis:M?][Australis:P2] → [Australis:P2][fixed-in-fx-team]
https://hg.mozilla.org/mozilla-central/rev/dc10b8966344
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Whiteboard: [Australis:P2][fixed-in-fx-team] → [Australis:P2]
Target Milestone: --- → Firefox 28
(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.
Blocks: 881937
You need to log in before you can comment on or make changes to this bug.