1333161 - Ctrl-A from input elements fails to write to primary selection on Linux

Status: NEW

(Core :: DOM: Editor, defect)

Description

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

I fiddled around with https://github.com/issues?utf8=%E2%9C%93&q=assignee%3Adjmitche until I found a search expression I liked, then attempted to copy/paste into my terminal.  I got the previous thing I had copied.

Steps to Reproduce:

1. Go to https://github.com/issues
2. Type something in the search box, hit enter
3. Hit ctrl-a to select the text box, and ctrl-c to copy
4. Open an editor in a terminal
5. Paste

Expected:
 Contents of the search box pasted into editor

Actual:
 Whatever was previously in my clipboard is pasted

NOTES:

 - This has been going on for quite a while, but for a long time I assumed I was missing the ctrl-c or otherwise committing user error
 - I can reproduce this now with the "summary" text box in the bugzilla form I'm filling out.  But I can copy/paste from the description box.
 - Pasting back into Firefox works fine.  What fails is specifically pasting into a urxvt256 window, with settings

URxvt.perl-lib:         /usr/lib64/urxvt/perl/
URxvt.perl-ext-common:
URxvt.perl-ext: confirm-paste,readline,selection-to-clipboard,matcher,font-size

Removing confirm-paste doesn't seem to make a difference (in fact, I added it mostly because of this issue: pasting 1000 lines of logs into the terminal is no fun)

Running this little shell command is revealing:

echo 'primary'; xsel -p; echo; echo 'secondary'; xsel -s; echo 'clipboard'; xsel -b; echo

I copied the paragraph above and ran the command:

dustin@hopper ~ $ echo 'primary'; xsel -p; echo; echo 'secondary'; xsel -s; echo 'clipboard'; xsel -b; echo
primary
Running this little shell command is revealing:
secondary
clipboard
Running this little shell command is revealing:

then copied from the summary and ran it again:

dustin@hopper ~ $ echo 'primary'; xsel -p; echo; echo 'secondary'; xsel -s; echo 'clipboard'; xsel -b; echo
primary
Running this little shell command is revealing:
secondary
clipboard
Copy/paste fails to write to primary selection on Linux

as you can see, the summary is placed on the primary, but not the clipboard.

Comment 1

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

Disabling both selection-to-clipboard and confirm-paste seems to make no difference, either.

Comment 2

[Abe - QA (:Abe_LV)]

Attachment: aboutSupport.txt

Hi Dustin,

I tested this on Ubuntu 16.04 64bits with latest nightly, but could not manage to reproduce.

Here is the screen capture: https://testing-1.tinytake.com/sf/MTI5NzIyMV80ODI4NjMx
I also attached about:support info. Is this a regression?

Comment 3

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

It is a regression, but I can't say from when -- I assumed for a long time that I was just bad at hitting ctrl-c, since in terminal just making a selection copies.

I'm using Fedora 24 with a tiling window manager (i3), if that makes a difference.

The thing you missed in trying to reproduce is copying from an input element and running the script from comment 0.  I don't have a good way to make a neat screen video like yours, but I can try some written steps:

1. Copy the following line, without the newline (just up to and including the final "o"):
  echo 'primary'; xsel -p; echo; echo 'clipboard'; xsel -b; echo
2. Paste into a shell command-line.  Do not hit enter.
3. Copy the following line to by selecting it and hitting ctrl-c:
  COPIED FROM A <PRE> ELEMENT
4. At the top of this bugzilla page, in the search box, type "COPIED FROM <INPUT> ELEMENT"
5. Ctrl-A
6. Ctrl-C
7. Switch to your terminal and hit Enter to run the command pasted earlier

Expected output:

primary
COPIED FROM <INPUT> ELEMENT
clipboard
COPIED FROM <INPUT> ELEMENT

Actual output:

primary
COPIED FROM A <PRE> ELEMENT
clipboard
COPIED FROM <INPUT> ELEMENT

Comment 4

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

Attachment: aboutSupport.txt

Comment 5

[Andrew Overholt [:overholt]]

Henri, do you know what code does this? I can't reproduce on Windows.

Comment 6

[Henri Sivonen (:hsivonen)]

The relevant code is in https://dxr.mozilla.org/mozilla-central/source/widget/gtk/nsClipboard.cpp . We use the Gtk facilities for exporting stuff to the clipboard. In particular, we rely on Gtk to abstract over the horrors of legacy non-UTF-8 X11 clipboard formats.

Copying in Firefox and pasting works for me to Firefox, gedit, Sublime, LibreOffice, Eclipse and Gnome Terminal.

Reporter, does copying from other Gtk3 apps work the way you expect?

Comment 7

[Henri Sivonen (:hsivonen)]

(In reply to Dustin J. Mitchell [:dustin] from comment #3)
> It is a regression, but I can't say from when -- I assumed for a long time
> that I was just bad at hitting ctrl-c, since in terminal just making a
> selection copies.
> 
> I'm using Fedora 24 with a tiling window manager (i3), if that makes a
> difference.
> 
> The thing you missed in trying to reproduce is copying from an input element
> and running the script from comment 0.  I don't have a good way to make a
> neat screen video like yours, but I can try some written steps:
> 
> 1. Copy the following line, without the newline (just up to and including
> the final "o"):
>   echo 'primary'; xsel -p; echo; echo 'clipboard'; xsel -b; echo
> 2. Paste into a shell command-line.  Do not hit enter.
> 3. Copy the following line to by selecting it and hitting ctrl-c:
>   COPIED FROM A <PRE> ELEMENT
> 4. At the top of this bugzilla page, in the search box, type "COPIED FROM
> <INPUT> ELEMENT"
> 5. Ctrl-A
> 6. Ctrl-C
> 7. Switch to your terminal and hit Enter to run the command pasted earlier
> 
> Expected output:
> 
> primary
> COPIED FROM <INPUT> ELEMENT
> clipboard
> COPIED FROM <INPUT> ELEMENT
> 
> Actual output:
> 
> primary
> COPIED FROM A <PRE> ELEMENT
> clipboard
> COPIED FROM <INPUT> ELEMENT

I can repro this with Gnome Terminal on Ubuntu 16.04. I'll need to refresh my memory regarding the Gtk philosophy regarding various X selections and clipboards.

Comment 8

[Henri Sivonen (:hsivonen)]

The starting point for searching the bug should be looking for differences in Gtk Clipboard.cpp handling for text/unicode and text/html clipboard flavors (especially the text/unicode alternative representation for the latter).

Comment 9

[Karl Tomlinson (:karlt)]

This behaviour goes back at least as far as 37.0b3.

Ctrl-c is expected to modify the clipboard selection, but not the primary.

The bug is that Ctrl-a should modify the primary, as in other GTK apps, but
that is not happening in input elements.  It does happen in input elements
with "Select All" from the Edit menu, and it does happen with Ctrl-a when
focus is on a textarea or the whole of a bugzilla page.

This command is useful:

  watch -n 1 "echo 'primary'; xsel -p; echo; echo 'clipboard'; xsel -b"

In GtkEntry (as used by input elements), Ctrl-a moves to beginning of buffer and then selects to end:
https://git.gnome.org/browse/gtk+/tree/gtk/gtkentry.c?h=3.22.8#n1939

I don't know why that doesn't modify the primary because Shift-End does.
Shift-End is select to end of buffer:
https://git.gnome.org/browse/gtk+/tree/gtk/gtkentry.c?h=3.22.8#n1930

I would expect those to execute the same code:
http://searchfox.org/mozilla-central/rev/12cf11303392edac9f1da0c02e3d9ad2ecc8f4d3/widget/gtk/NativeKeyBindings.cpp#164

Comment 10

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

Moving all open Keyboard/IME handling bugs to DOM: UI Events & Focus Handling component.

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Comment 13

[mbagnara]

Attachment: debug-info

This bug also appears to affect the ability to bring the address bar contents into the primary selection buffer when single clicking it to select-all.