Created attachment 162825 [details] FailToPasteColumnBugB1.ods test data Reproduction procedure: test1 FailToPasteColumnBugB1.ods 1. select column A by clicking column header "A" 2. ctrl+C to copy by this, whole column A will be blue 3. click column header B by this, whole column B will be blue 4. shift+click column Y by this, whole columns B:Y will be blue 5. ctrl+V to paste -> result: problem: nothing pasted test2 1. re-open file. repeat test1.1-3 4. now shift+click column X by this, whole columns B:X will be blue -> result: correctly pasted. content of column A repeatedly filled into each column of B:X Reproducibility: 100% at any file. Don't even need to re-open file. Can retry procedure by Undo (ctrl+Z). Notes: * copy-pasting rows has no such problem, at least for 100 rows. * copy-pasting individual cells or a finite range of cells have no such problem. * Excel2000 does correctly paste, at least over 100 columns (tested with range B:EZ). * When you drag-selecting the paste range, the paste works correctly for a broader range. But I need chift-click style range selection when I want to paste into say 500 columns, because drag-selecting a range of 500 columns is too cumbersome and prone of mis-operation. The most puzzling (worrying) thing is the rationale behind this magic number. Why 23?
Correction: > zzz 2020-07-09 05:30:11 UTC >* When you drag-selecting the paste range, the paste works correctly > for a broader range. Now I cannot reproduce this success case. Now, drag-selecting the paste range B:Y and ctrl+V into that will also fail to paste anything as well, reproducitibility 100% (5/5 times in 2 files).
Repro already with oldest of linux-64-6.3 bibisect repository, but not yet with latest of 50max repo.
Nice report. Bibisect 5.2 Linux: commit 0faad65737329a9b8365f4164653620880b5bfea Date: Tue Dec 19 06:51:16 2017 +0100 source 7dda28234cc516e864aff9a6c97b7c539a063c4e previous d013a5a38c6460a22434c6ba637c63d2118f12dc Single commit: author Eike Rathke <erack@redhat.com> 2016-07-29 18:18:01 +0200 committer Caolán McNamara <caolanm@redhat.com> 2016-08-02 15:15:02 +0000 commit 7dda28234cc516e864aff9a6c97b7c539a063c4e (patch) tree bcbafa58d49fb9069f8b7a7d02f89f47640a37f8 parent d013a5a38c6460a22434c6ba637c63d2118f12dc (diff) limit SelectionFillDOOM to 24117248 cells, tdf#60021 tdf#60056 related CC: Eike. Please see this and comment on "magic number" of 23.
What magic number would you like instead? 42? I chose the discordian 23 because it breaks up something.. The point in this behaviour is to prevent a "paste something into the entire selected range". Which happens if only one cell (or a range of data) was copied, pasting that onto entire selected columns will repeat the data over the selection to fill it up. Which usually leads to out of memory. Having copied an entire column first including all empty cells is a somewhat special case though (there can be no repetition). Which that checking code does not know about. Fwiw, pasting such copied entire columns works if the target range is not selected as entire columns but only as first cell starting positions like in any other normal paste operation, e.g. B1:EZ1 (hit Shift+Ctrl+T to focus the Name Box and enter B1:EZ1 and hit Enter, after which the range is selected).
This is closest to WontFix.
42 should be fine, it's the solution to the whole universe:-) Well, I am very surprised that such magic number is embedded, especially in a spreadsheet software. Arbitrary limitations like that will eventually bring all kinds of perils. The mere fact that just figuring out the cause of this case took one year is a good evidence. Anyway, thanks for proposing a workaround. The problem with such a single-row target area is that it is counter-intuitive. I usually do the copy-column when I want to replicate the column width. For a single row target: (a)If the source is a finite range of rows, then the target column width does NOT change. (b)If the source is an infinite range of rows, then the target column width DOES change to the source width. So user must remember this whole inconsistency. It is also inconsistent with the interface of how to insert new columns, and how to insert-paste. This is how you have to teach users now: - If you want to insert-replicate columns, first consider whether you want to make over 23 columns. If no, then select the source columns, command-copy, then select the target region by selecting some arbitrarily finite rows, such as B1:EZ1, and then command paste. Oh, when you paste, don't forget to set the PasteSpecial|Selection|Formats|On, otherwise you will fail and have to do it again. Now, if you want to make over 23 columns, then you have to do another preparation. First insert the extra columns you want to add, then do the same procedure as above, ie. select the source columns, command-copy, then select the target region by selecting some arbitrarily finite rows, such as B1:EZ1, and then command paste. Oh, when you paste, don't forget to set the PasteSpecial|Selection|Formats|On, otherwise you will fail and have to do it again. Oh, wait, first check the release note because the limitation may have changed to 42. The URL of the release note is... Who wants to make such manual, help tooltip, or do such tutoring? Quite unproductive. Conclusion: The usefulness and ease-of-learn of spreadsheets stem from their fundamental mental model: "Any amount of empty cells can be treated as really empty". So keep that.
(In reply to zzz from comment #6) > The mere fact that just figuring out the cause of > this case took one year is a good evidence. Nonsense. I was made aware of this just today by being Cc'ed with comment 3.
(In reply to Timur from comment #5) > This is closest to WontFix. Actually no. I'd rather have this case of copy-pasting entire columns onto entire columns covered and exempted.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/fddef05ea72db3450f95570a17511350cc46016b Resolves: tdf#134675 Allow unrestricted pastes of same size in one dimension It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Verified in Version: 7.2.0.0.alpha1+ / LibreOffice Community Build ID: 42d2b2d55a27f11153ea1713737d93540a19211d CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded @Eike, thanks for fixing this issue!!
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/27192c82ab143287327367d6165737086613021f tdf#134675: sc_uicalc: Add unittest It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-7-1": https://git.libreoffice.org/core/commit/29e74f1ef0a608ce37cbc2a3dd527b4b22e77cca Resolves: tdf#134675 Allow unrestricted pastes of same size in one dimension It will be available in 7.1.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.