STEPS TO REPRODUCE: 0. In Xorg (don't know about Wayland)... 1. Create or open a calc spreadsheet 2. In a terminal (e.g. gnome-terminal) select some text with the mouse 3. Click in an empty spreadsheet cell and middle-click (selected text appears the spreadsheet cell as expected) 4. Type any key on the keyboard RESULTS: The pasted text vanishes from the cell This happens only if the middle-click paste is the first thing entered; subsequent middle-click-pasted content is not erased by typing in that cell. The problem re-appears when starting in a new empty cell, or the same cell after deleting existing content. Note: Middle-click in the X Window system (or equivalent keyboard shortcut, if enabled), pastes the "PRIMARY selection" which is whatever is currently selected by the mouse in any window. It is independent of the "clipboard" used by Ctl-C/Ctl-V. Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 16a35542aa07ed69c6c699d1c17f076d87708958 CPU threads: 12; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
I tried under Wayland (at least I think it was...) and the problem is the same.
The same problem happens with Control-V paste from the clipboard, so not specifically related to the X "PRIMARY" selection buffer. Sorry about the unnecessary complication. I changed the title to just say "paste".
You described what actually happened. What was supposed to be the expected behavior after step 4 in your comment 0?
> What was supposed to be the expected behavior after step 4 Continue to accept input, i.e. append what is typed after what was pasted with the mouse... just like what happens in a terminal, in LO writer, or most anywhere else. By the way, DOUBLE-clicking in a cell before pasting avoids the problem. It seems like a single-click followed by paste (middle-mouse or Ctl-V) sets up the condition for subsequent keystrokes to erase the pasted text.
(In reply to Jim Avera from comment #4) > > What was supposed to be the expected behavior after step 4 > > Continue to accept input, i.e. append what is typed after what was pasted > with the mouse... just like what happens in a terminal, in LO writer, or > most anywhere else. > > By the way, DOUBLE-clicking in a cell before pasting avoids the problem. It > seems like a single-click followed by paste (middle-mouse or Ctl-V) sets up > the condition for subsequent keystrokes to erase the pasted text. Double click means entering into edit mode. Single click means focusing only (which is not even selection). If you used [CTRL]+[V], you have pasted something and you are no longer in edit mode, so typing something new starts a replacement of the content of the cell, unless you use [ESC] instead of [ENTER] after the newly typed-in characters. As for the other method, I guess it depends on OS and DE.
> If you used [CTRL]+[V], you have pasted something and you are no longer in edit mode, so typing something new starts a replacement of the content of the cell That's what I think isn't right. Pasting and then typing should be the equivalent of typing both pieces. I don't think pasting and typing should be considered unrelated actions, but just alternate ways to provide input which can be interleaved any way the user wants. That is the model used by every other application I use (admittedly Linux-centric).
(In reply to Jim Avera from comment #6) > That's what I think isn't right. Pasting and then typing should be the > equivalent of typing both pieces. Again, the status is different if you are (already) in cell's edition mode, or not. If you are already in edit mode and you type in (or paste) characters, then you are adding text to whatever there is already in the cell, and its position depends on where exactly the cursor was located at the time. If you are already in edit mode, and some text is selected within the cell before typing in, then you would be replacing the selection. If you are not in cell's edition mode, then you are introducing characters into the cell, whether there was/is something in the cell previously or not. In the above descriptions, I am not getting into the whole insert/replace alternative writing modes. IMHO, if there is some possible enhancement to be made, the expected behavior and actions (step by step) should be described more accurately. Someone else might find this report (RFE?) more clear than I do.
(In reply to ady from comment #7) > If you are not in cell's edition mode, then you are introducing characters > into the cell, whether there was/is something in the cell previously or not. I should had clarify that, in that case, you would be introducing characters in the cell, and whatever was in there before, is not relevant in terms of content. What was there before, would be gone in that case.
@ady I think we are talking past each other. What you said about edit mode is clear. The problem I see is that the initial paste does not enter edit mode, but typing does. They should (IMO) be handled the same. For example, if user clicks once and types "A", the "A" replaces existing content; fine. If the user then types "B", it is appended and does not erase the "A", and so-forth. In the same way, if the user clicks once and pastes "A", it replaces existing content; fine. But the next user input erases the "A" when it should append. What I am saying is that pasting should have *exactly* the same effects as typing the same content on the keyboard. Everywhere. -Jim
A very controversial proposal, alerting UX team
What do you expect to happen for multiple-cells content, eg. "1<tab>2<tab>3"? And what, if the clipboard contains an image? What scenario makes it necessary to modify the pasted content (thinking of the opposite where users definitely do not want to change the pasted data but have to press escape to leave the edit mode)?
> [pasting] multiple-cells content, eg. "1<tab>2<tab>3"? Doesn't the same thing happen if you type those 5 keystrokes instead of pasting them, i.e. a tab advances to the next cell? If not, what is the desired difference in behavior (between pasting multiple cells and typing 1<tab>2 etc.)? > What if the clipboard contains an image? What should happen, for the best user experience? Current behavior is anomalous: If you click once in a cell and paste an image, the image overlays any text in the cell, but the image is anchored *to the page* not to the cell so the image will move to cover random other cell(s) when row heights change; If you double-click to enter edit mode, then LO refuses to paste an image (Ctl-V does nothing). My first thought is that images should by default be treated like characters, so mixing characters and images can be done usefully: If in edit mode, then Ctl-V with an image in the cb would paste the image and anchor it to the preceding character, offset horizontally to start just after that character; if there is no preceding character then anchor to the cell at the upper-left corner. I don't understand why anchoring to the page is ever useful, but a user could always change the "Anchor" property after pasting if they wanted that. > What scenario makes it necessary to modify the pasted content (thinking of the opposite where users definitely do not want to change the pasted data but have to press escape to leave the edit mode)? I'm not sure I understand this question. I'm saying LO should *not* modify the pasted content (currently it does -- it *deletes* pasted content when something else is input). If a user pastes and then types backspace, then yes the pasted content should be modified; but in that case the user explicitly initiated the modification.
[Automated Action] NeedInfo-To-Unconfirmed
(In reply to Jim Avera from comment #12) > I'm not sure I understand this question. We have to balance your workflow with how the average user deals with the program. I believe there are as many scenarios where "overwriting" is desired. And the other questions were kind of rhetorical to illustrate potential inconsistencies. But anyway, we will discuss the proposal in the design meeting.
I disagree with this proposal. If you want to be in edit mode just double click on needed cell before pasting. It works so in any spreadsheet software and we shouldn't change this behaviour
The topic was on the agenda at the design meeting but did not receive further input. It's easy to switch into the edit mode, in edit mode you cannot go to another cell, and the idea has flaws regarding multiple cells. The workflow not not overwrite content is not the common one, and would be a fact for multiple cells anyway.