1275932 - Ctrl-C intermittently fails to copy

Status: RESOLVED FIXED

(Firefox :: General, defect, P1)

Description

[Chris AtLee [:catlee]]

Firefox occasionally fails to actually copy when I press Ctrl-C with the cursor on highlighted text in the location bar, or in a web page.

A common pattern I use is:
- Ctrl-L (highlight location)
- Ctrl-C (copy)
- Navigate to other window
- Ctrl-V (paste)

I estimate that this fails about 5% of the time. What happens is that the previous contents of the clipboard are pasted instead, so I assume that the copy-to-clipboard isn't actually working.

This results in mostly irrelevant, sometimes embarrassing, and occasionally dangerous pasting of unexpected contents into public channels.

This is not a recent regression; Firefox has been behaving like this for a while.

Comment 1

[Dustin J. Mitchell [:dustin] (he/him)]

I've been seeing this too.  Given the low incidence rate, it took quite a while to convince myself it wasn't just me.

Catlee and I both use Linux.

Comment 2

[Greg Arndt [:garndt]]

I have experienced this issue as well running on OS X with developer edition.

Comment 3

[Chris AtLee [:catlee]]

I was able to reproduce this issue pretty reliably with the primary clipboard (select to copy / middle-click to paste) by doing this:

- Select some text in firefox
- Middle click in another window to verify it pastes
- Ctrl-L in Firefox
- Middle click in other window

Most of the time it pastes the old contents.

Comment 4

[Amy Rich [:arr] [:arich]]

Me, too: dev edition on OS X 10.11

Comment 5

[Andrew Comminos [:acomminos]]

I can reproduce this reliably as well using Ctrl-L to focus with the PRIMARY selection.

Curiously, it seems to copy fine after a second press of Ctrl-L (pressing Ctrl-L while the URL bar is already highlighted).

Comment 6

[Andrew Comminos [:acomminos]]

This doesn't seem to happen with e10s off fwiw.

If you highlight the search bar then the address bar (Ctrl-K -> Ctrl-L) the address bar selection gets copied just fine.

Judging from this, I'm thinking that the use of our GTK backend's nsClipboard out-of-process is at fault here.

Comment 7

[Clément Lefèvre]

(In reply to Andrew Comminos [:acomminos] from comment #6)
> This doesn't seem to happen with e10s off fwiw.
> 
> If you highlight the search bar then the address bar (Ctrl-K -> Ctrl-L) the
> address bar selection gets copied just fine.
> 
> Judging from this, I'm thinking that the use of our GTK backend's
> nsClipboard out-of-process is at fault here.

I think I actually noticed it sometimes on Firefox stable, so without e10s. I'll pay more attention the next time this is happening to be sure/confirm this.

And does it concern GTK if this is happening on OS X too?

Comment 8

[Dustin J. Mitchell [:dustin] (he/him)]

I'm running stable, too (Firefox 45).(In reply to Chris AtLee [:catlee] from comment #3)
> - Ctrl-L in Firefox
> - Middle click in other window

did you intentionally omit Ctrl-C here?

Comment 9

[Chris AtLee [:catlee]]

(In reply to Dustin J. Mitchell [:dustin] from comment #8)
> I'm running stable, too (Firefox 45).(In reply to Chris AtLee [:catlee] from
> comment #3)
> > - Ctrl-L in Firefox
> > - Middle click in other window
> 
> did you intentionally omit Ctrl-C here?

yes, this is testing the selection-based copy.

Comment 10

[Dustin J. Mitchell [:dustin] (he/him)]

OK, that very reliably *never* works for me.

Comment 11

[Chris AtLee [:catlee]]

It works reliably for me if you press Ctrl-L twice.

Comment 12

[Dustin J. Mitchell [:dustin] (he/him)]

I just did the following:

 * select an address in a tab
 * ctrl-c, ctrl-t, ctrl-v, enter
 * tab opens to the URL that was previously in my clipboard

(I realize this isn't a selection-based copy issue, and isn't about copying from the location bar.  If we have multiple bugs here, I'm happy to split this up)

Comment 13

[Andrew Comminos [:acomminos]]

Amending my previous comment; it doesn't look like the issue is at the widget level. nsClipboard::SetData is simply not called for the first selection when pressing Ctrl-L after making a selection in the content process.

Comment 14

[Neil Deakin]

The selection code for the urlbar is at https://mxr.mozilla.org/mozilla-central/source/browser/base/content/urlbarBindings.xml#1034

I'll bet the isHandlingUserInput check is failing because the event is being handled in the other process.

Comment 15

[Neil Deakin]

Attachment: Set handling user input before refiring key event

Comment 16

[Neil Deakin]

Attachment: Set handling user input before refiring key event, fix compile error

Comment 17

[Neil Deakin]

https://hg.mozilla.org/integration/mozilla-inbound/rev/81fa78eb62f6ff8eb0b392105e43b7122f04df90
Bug 1275932, use AutoHandlingUserInputStatePusher to indicate that a real input is happening when refiring key event in the parent process, r=masayuki

Comment 18

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/81fa78eb62f6

Comment 19

[Chris AtLee [:catlee]]

I just had this happen again in Nightly