Bug 133545 - Tooltip in case of the hard-coded paste limit of 24117248 cells
Summary: Tooltip in case of the hard-coded paste limit of 24117248 cells
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.3.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Paste
  Show dependency treegraph
 
Reported: 2020-05-31 10:04 UTC by Telesto
Modified: 2023-05-13 13:11 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file (9.61 KB, application/vnd.oasis.opendocument.text)
2020-05-31 10:05 UTC, Telesto
Details
Proper Example file (8.21 KB, application/vnd.oasis.opendocument.spreadsheet)
2020-05-31 15:29 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-05-31 10:04:59 UTC
Description:
Replace hard-coded paste limit to 24117248 cells with a warning dialog 

Steps to Reproduce:
1. Open the attached file
2. Select Cell A1
3. Select Columns until Z -> not able to paste/paste disable
4. Select columns until W -> able to paste

Actual Results:
Paste is disabled for a unknown reason (only bibisect reveals)

Expected Results:
Replace the hard coded cell limit with a dialog.. people should be able to do somewhat stupid things.. not an arbitrary limit.. I didn't know why I couldn't paste until Z.. And yes, this is doable.. without crash.. x64. So the limit is actually 'low' 


Reproducible: Always


User Profile Reset: No



Additional Info:
author	Eike Rathke <erack@redhat.com>	2016-07-29 18:18:01 +0200
committer	Eike Rathke <erack@redhat.com>	2016-07-29 18:25:28 +0200
commit 5cf5975cef114870268bee792e44570ddfdaafe8 (patch)
tree f89d7310d2f3365bd2ebecc3b8fffd1930a09bd6
parent 1203bf57dea230cd6de7bb5fe359d8fcd3e033dc (diff)
limit SelectionFillDOOM to 24117248 cells, tdf#60021 tdf#60056 related

https://cgit.freedesktop.org/libreoffice/core/commit/?id=5cf5975cef114870268bee792e44570ddfdaafe8
Comment 1 Telesto 2020-05-31 10:05:14 UTC
Created attachment 161453 [details]
Example file
Comment 2 m_a_riosv 2020-05-31 13:22:49 UTC
Attachment it's a writer file.

I never experience such limit.

There is a new option on Menu/Tools/Options/LIbreOffice Calc/Defaults - Enable very large spreadsheets, with v7
Comment 3 Telesto 2020-05-31 15:29:48 UTC
Created attachment 161461 [details]
Proper Example file
Comment 4 m_a_riosv 2020-06-01 07:20:01 UTC
Confirmed
Versión: 6.4.4.2 (x64)
Id. de compilación: 3d775be2011f3886db32dfd395a6a6d1ca2630ff
Subprocs. CPU: 4; SO: Windows 10.0 Build 19608; Repres. IU: GL; VCL: win; 
Configuración regional: es-ES (es_ES); Idioma de IU: es-ES Calc: CL
Comment 5 Eike Rathke 2020-06-02 11:29:28 UTC
Ask yourself how useful it is to copy one cell to more than 23 million cells..

Take into account that this limit exists to prevent users from shooting themselves into the foot by selecting too many entire columns (or worse, with Ctrl+A the entire sheet) before pasting that could crash the application if not enough memory was available. Maybe pasting one text cell (where the actual string is shared and not replicated) is ok on your system and the memory used looks "low" to you, but make it a number, or heavier, a not so trivial formula.

See also the bugs referenced by the commit, tdf#60021 and tdf#60056.

I advise against removing the limit.
Comment 6 Eike Rathke 2020-06-02 11:32:36 UTC
Enabling the paste option nevertheless just to raise a warning dialog when executing it doesn't look like a better UX to me either.
Comment 7 Heiko Tietze 2020-06-02 12:24:55 UTC
Confirmation/warning dialogs interrupt the workflow and are kind of last resort for feedback, eg. when it comes to safety relevant information or data integrity. In this case, I would simply add a tooltip to the disabled button telling the reason. This is a common, unfortunately not too often applied method of feedback.

Could be an easy hack.
Comment 8 QA Administrators 2022-06-05 03:40:43 UTC
Dear Telesto,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug