Created attachment 126486 [details] Demonstration of the problem reduced to the bare minimum The combination of a split view and the use of custom functions written in BASIC, can cause calc not to display correctly the contents of some cells. To reproduce: ============== - Open the attached document (WARNING: contains macros, which must be activated to demonstrate issue) - Split the view horizontally and scroll the upper view to the top of the spreadsheet. The lower view should show the highlighted cell at row 50 - In the upper View, write any value to cell A1 and hit enter --> Cell A1 shows as empty, even though it (correctly) contains the value just entered. --> After editing any other cell, the contents of A1 will "appear" Additional information: ======================== - The problem occurs only for cells that are referenced by a function written in BASIC - The function must be rather "long" to calculate for the problem to show. Alternatively, the problem also shows with a function that takes less cycles, but is used in several cells. (see Example2 in the attachement) - The problem shows also with the view split horizontally, in this case the function(s) must be in a cell to the right of A1. - Inverting the positions for the "value cell" and the "function cell" the problem does NOT reproduce. (i.e. everything works as expected)
No problem here. Maybe try with a newer version: https://wiki.documentfoundation.org/Installing_in_parallel/Linux Arch Linux 64-bit, KDE Plasma 5 Version: 5.2.0.4 Build ID: 5.2.0-1 CPU Threads: 8; OS Version: Linux 4.6; UI Render: default; Locale: fi-FI (fi_FI.UTF-8)
Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
The Bug still shows with LO 5.3.3.2 - not with the attached document though. I'll add a slightly modifyied version of the document that shows the problem on my system. The reason why Buovjaga could not reproduce the problem might be that his machine is more performant than mine. If you cannot reproduce the problem, please try to increase the cycles of the for loop in the TEST_FOR macro (Example 1).
Created attachment 134239 [details] Demonstration of the problem reduced to the bare minimum - v2
(In reply to Simon from comment #4) > Created attachment 134239 [details] > Demonstration of the problem reduced to the bare minimum - v2 With this document, I could immediately reproduce it by deleting A1 - the number 5 stayed there until I edited some other cell. Likewise, inputting something to A1 did not show it immediately. With 3.6 it is ok. Arch Linux 64-bit, KDE Plasma 5 Version: 6.0.0.0.alpha0+ Build ID: 5ff95b16cf9fb2ac7b2b970614e3b98f55978dc0 CPU threads: 8; OS: Linux 4.11; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on June 23rd 2017 Arch Linux 64-bit Version 3.6.7.2 (Build ID: e183d5b)
This seems to have begun at the below commit. Adding Cc: to Tomaž Vajngerl ; Could you possibly take a look at this one? Thanks db76ebae674812c4c3dffafc2d02201a67dd15a7 is the first bad commit commit db76ebae674812c4c3dffafc2d02201a67dd15a7 Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Wed Jun 3 14:29:56 2015 -0500 source dca01def7885ad69cf66edd75cf8207a5adb64f9 source dca01def7885ad69cf66edd75cf8207a5adb64f9 author Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk> 2015-05-07 14:18:37 +0900 committer Jan Holesovsky <kendy@collabora.com> 2015-05-07 09:57:50 +0200 commit dca01def7885ad69cf66edd75cf8207a5adb64f9 (patch) tree f3b43717ab058b677c68614bcb2953beb7c7d1a0 parent 7a11ec1992bf877f42edce8d1d930c5b00bd3d48 (diff) refactor ListBox/ComboBox to use RenderContext Change-Id: I367d6e4f54375bd61e46f0c1437444306b127c68
Dear Simon, 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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Reverting the above commit doesn't fix the problem for me, so I re-bisected this, which lead to the scheduler rewrite in 4.4 -> 5.0 timeframe. The core.git commit range is 1028643bc7d294e4c32b4ccea288d90088abae53..01f406bc28f53acc5a2734af637aa8074a5d1813, but I could not bisect further as the code doesn't build. Adding Cc: to Tobias Madl; Could you possibly take a look at this one? And removing from the "List-Combobox-RenderContext-regressions" tracker.
Dear Simon, 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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
This seems to be fixed since LO 7.1's author Caolán McNamara on 2020-10-16 12:54:14 +0200 commit e087e25f05e689091cbf1c4f91b6e93878ac17ec weld InputBar this also restores that DnD of a selection from the inputbar is pasted as plain text not rich text formatted with the happenstance formatting of the inputbar's EditEngine