Description: When copying and pasting a large amount of data (100000 rows) from Excel in the web browser (e.g. Edge) to Calc, an error string is displayed in the Calc paste cell stating the amount of data is too large. Steps to Reproduce: 1.Open the file attachment in a Web Browser that supports Excel Online (e.g. Edge on Win10). 2.Copy the text from cell 1 to 100000 3.Paste into Calc Actual Results: Error message is displayed in Paste cell: "The selection you're trying to copy and paste is too large. Select a smaller set of data and try again." Expected Results: All 100000 rows are pasted Reproducible: Always User Profile Reset: No Additional Info: Tested using latest Edge on Win10 with free version of Excel online.
Created attachment 188283 [details] Excel file with 100000 rows
See Bug 127675 for debug info
I think it's the same issue as in tdf#127675, but instead calc->excel is excel-calc. BTW, pasting as unformatted text works for me. And the options to past are more limited than from excel in the computer. For me, should be closed as duplicate, adding the information specific about web-excel there.
(In reply to m.a.riosv from comment #3) > For me, should be closed as duplicate, adding the information specific about > web-excel there. I did add the information there but it was suggested to open a new bug for the different copy program (web browser vs. excel).
I debugged the code and it looks like there's a difference between pasting as HTML and pasting as a binary format. LibreOffice seems to only intercept it as HTML_SIMPLE, not as binary. In that case, the copied selection in HTML correctly shows an error message, because Excel Online copied an error message into the HTML on the clipboard (there is no row/col data). Is there a way to make LibreOffice interpret the data as binary?
(In reply to Matt K from comment #5) > Is there a way to make LibreOffice interpret the data as binary? And do we want to hardcore a check for the error message from Excel online, or just always interpret as binary and never as HTML?
Fix is tracked in https://gerrit.libreoffice.org/c/core/+/154491. Added Mike to the review.
I believe this should not be fixed. As you know, the problem is that the *source* data (HTML) coming from Excel Online already contains the error - they simply refuse to copy that large piece into HTML clipboard format; yet, they provide the data in plain text formats. Basically, that is a *bug* in the behavior of Excel Online. Microsoft documentation on the clipboard formats [1] tells: > A window can place more than one object on the clipboard, each representing > *the same information* in a different clipboard format. I emphasized "the same information", which is what they fail to do here. Receiving end (Calc) must not assume different data in different formats; the rule is that the receiving application decides which format to use, based on the richness of the data in the supported formats, not on the actual content. See there: > Clipboard formats that contain the most information should be placed on the clipboard > first, followed by less descriptive formats. A window pasting information from the > clipboard typically retrieves a clipboard object in the first format it recognizes. > Because clipboard formats are enumerated in the order they are placed on the clipboard, > the first recognized format is also the most descriptive. In reality, of course, it's not that simple, because "the first recognized format", while might really be more descriptive, may be supported to a lesser extent; and also, not all applications follow the "most descriptive format first". But this is orthogonal. In the frame of this issue, Calc does the correct thing, choosing HTML. User may do a special paste, using plain text - of course, most will not realize that it would change the result, exactly because of the same natural expectation that is broken by MS here. Excel Online could at least do something a little bit smarter, and amend *their* text with a note that "pasting as plain text could work". It is normal to paste non-tabular data to Calc. The proposed change would break that scenario. So - WONTFIX. [1] https://learn.microsoft.com/en-us/windows/win32/dataxchg/clipboard-formats