Problem description: On a multi-sheet spreadsheet, when Window:Freeze is set on a sheet, Calc does not register the address of a cell in another sheet when inputting a formula. Steps to reproduce: 1. Set Window-Freeze 2. Start entering a formula in a cell. Press "=" and click the tab of another sheet, then click a cell in that sheet. The input bar does not show the clicked address. 3. Press Return. The formula cell contains only "=" To avoid this, unfreeze the window and enter the formula. Platform (if different from the browser): Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_5_8) AppleWebKit/534.50.2 (KHTML, like Gecko) Version/5.0.6 Safari/533.22.3 This is in LibO 3.5.1 RC2
Thanks for bugreport reproduced in 3.3.4 and 3.5.4 on Fedora 64 bit (Windows not tested) Changing version to 3.3.4 as most early reproduced
*** Bug 51731 has been marked as a duplicate of this bug. ***
[Reproducible] with parallel installation of Master "LOdev " 3.7.0.0.alpha0+ - WIN7 Home Premium (64bit) ENGLISH UI [Build ID: 3985521]" (tinderbox: W2008R2@16-minimal_build, pull time 2012-06-24): When I reference to cell in a different sheet from a cell in a "Frozen" sheet (outside the "Headings area" I will get a string "=" instead of reference to contents in different sheet. Problem only appears in the first 2 columns right from "freeze line" Same when 'Split Window' No problem when I open a second Window for the document (for second referenced sheet) and switch to second window after "=" for reference. Already reproducible with OOo 3.2, so inherited from OOo @Spreadsheet Team: Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug
If this is the same as bug #51731 you should only get this problem with cells which are 2 columns from the one from which Window-Freeze was started. Can you confirm this ? (ie: 3rd column off the freeze it is fine) Also bug #51731 lists another workaround: clicking in the formula input widget before selecting the target cell (to reset proper focus)
That is correct. Only the first 2 columns are affected. Seems to be immaterial which row. This is on LO 3.5.4.2, OS X 10.7.4 On 5 Jul 2012, at 06:52, bugzilla-daemon@freedesktop.org wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=47349 > > --- Comment #4 from strk@keybit.net 2012-07-05 05:52:37 UTC --- > If this is the same as bug #51731 you should only get this problem with cells > which are 2 columns from the one from which Window-Freeze was started. > Can you confirm this ? (ie: 3rd column off the freeze it is fine) > > Also bug #51731 lists another workaround: clicking in the formula input widget > before selecting the target cell (to reset proper focus) > > -- > Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You reported the bug.
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (4.3.5 or later): https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) Thank you for your help! -- The LibreOffice QA Team
No problem anymore. Win 7 Pro 64-bit Version: 4.5.0.0.alpha0+ Build ID: 07e84cae983c08afdba03018413a19d01abb3006 TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2015-01-19_06:15:38
*** Bug 105652 has been marked as a duplicate of this bug. ***
Created attachment 140671 [details] Test case
Reopening this as I don't think it ever was fixed (see comment on bug 105652) Attached is a test case from bug 105652, but with clearer repro instructions. Use the keyboard to start the formula entry, do not use the formula bar as that does not expose the bug
*** Bug 106133 has been marked as a duplicate of this bug. ***
*** Bug 78476 has been marked as a duplicate of this bug. ***
Still an issue - see also question on https://ask.libreoffice.org/en/question/223897/calc-transpose-fails-if-freeze-rows-columns-set/
*** Bug 113800 has been marked as a duplicate of this bug. ***
*** Bug 112514 has been marked as a duplicate of this bug. ***
On pc Debian x86-64 with master sources updated today, I can reproduce this if I freeze a column, not if I freeze a row.
This is the most annoying bug I have ever seen, as an extensive libreoffice Calc user in my daily life. What else debuging steps should we do (with a dbgutil build with symbols enabled) to help this bug fixed quickly? Could some devs give hints?
Upgrading to high importance - lots of CCs and more than 5 duplicates and has been reported for both Windows and Linux. A partial work-around is to click the mouse after the = (still in the cell). Yes, the cursor is already blinking there, but clicking there anyway refocuses it, and then it will pick up the other sheet reference. HOWEVER, when you return to the original sheet and click in a different cell, it does NOT replace the other sheet reference, but ADDs it in front. In some of my testing, it worked on sheets that were farther way, but not on directly adjacent sheets on either side. However, that wasn't always true. A key area to start debugging at looks to be sc/source/ui/app/inputhdl.cxx void ScInputHandler::SetReference ESelection aSel = pActiveView->GetSelection(); if ( aSel.nStartPara == 0 && aSel.nStartPos == 0 ) return; since nStartPos is reported as zero in the problematic columns.
Created attachment 167073 [details] 47349_debug.diff: debugging lines highlighting key parts in the problem. A regression-inviting patch is proposed at http://gerrit.libreoffice.org/c/core/+/105429.
Created attachment 167074 [details] freezePanes-splitWIndow.ods: same problem still remains for split window. While my patch does seem to fix a logic error in the previous code (at least to my uninformed mind), there is still something more fundamental that would be a better fix, as shown by this split-instead-of-freeze example.
(In reply to Justin L from comment #19) Thanks very much for the patch. I will build and test hard these days to see whether this patch does cause regressions. Should this be set ASSIGNED accordingly?
I have tested the patch and it works - so far I have not found any regression caused by this patch. Will continue test these days. However, as Justin has said, this is a "regression-invite" fix, and may cause some unknown regression errors. As a result, I have prepared a test package in the following link: https://go.suokunlong.cn:88/dl/libreoffice/daily/2020-11-08-test_tdf_47349_linux64.tar.bz2 This package contains the binary with and without that patch, and was compiled on Fedora 30 linux 64bit. Those who have a Linux machine are welcome to test. If you find a bug which exists in the one with the patch, but does not exist in the one without the patch, then that is certainly a regression caused by this commit. The best way to test is to use this build in your daily work (as what I have been doing), but be warned that it may cause data loss! Those who encounter slowness to download may give me an email, so that I can try to put the binary in a server outside China.
Hi Justin, LibreOffice 7.1 branch will be created on week 47 ( https://wiki.documentfoundation.org/ReleasePlan/7.1 ). I would propose to submit you patch to master after the branch off so we are plenty of time to test it What do you think ?
(In reply to Xisco Faulí from comment #23) > I would propose to submit your patch to master after the 7.1 branch off Well, I certainly agree it should NOT be done before that. However, I don't want it pushed even in 7.2 without a calc-expert review.
I do not know the code, but I have applied the patch even on 6.4 branch and have been used this for 5 days without noticing any regression, including on mission critical daily work. However, my test was on Fedora 32, not sure about other platforms.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/fed6c4c70da6b35d72b670c8f4d8e866cdac21e4 tdf#47349 sc ui: bPosVisible only for fully visible It will be available in 7.1.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.
Justin: Could you backport this to 7.0 branch as well? It shoild be just a cherry-pick. I am sure it is safe as I already tested it, but We certainly need Eike's review.
(In reply to Kevin Suo from comment #27) > Justin: Could you backport this to 7.0 branch as well? Definitely not. There would not be enough time to fix in 7 if it does end up causing problems for the many millions situations that you would not have thought of testing. In fact, I was hoping it wouldn't even make it into 7.1 - but oh well. I think my commit message made it pretty clear that I take no responsibility or credit for anything related to this patch.
(In reply to Justin L from comment #28) Understood. Thank you very much anyway for fixing this!
(In reply to Justin L from comment #28) > I was hoping it wouldn't even make it into 7.1 You are underestimating your capabilities :p But I agree we shouldn't backport it to 7-0
The same problem still exists if splitting is used instead of freezing, as indicated in Comment 20. Re-opening this bug instead of adding a new one because it contains good information and debugging, and because the fundamental issue likely would also have solved the freeze problem too.
repro 7.4+
I spent some time again in comment 20's attachment 167074 [details]. I noted that the focus seems to be on the bottom left quadrant (BL). Anytime the formula building starts from here, it work. Anytime the formula building starts from a different quadrant that is fully VISIBLE in BL, it doesn't work. But, if BL doesn't have the target cell as fully visible, then the formula building works on other sheets. (BL is used for an un-split view.) For example, when this document opens, my BL sees J7..AC17 (and part of 18). TL also can see AA2, so building a formula in there works. So does TL AC18, but not TL AC17. Similarly, TR AD14 works, but not TR AC14. (Adding another sheet with a split in it complicates things, BTW. The active cells in each have to be in the same quadrant before it works.) I can "fix" the problem in ScTabView::ZoomChanged() with if (!SC_MOD()->IsFormulaMode()) UpdateEditView() Or perhaps more to the point, in ScTabView::SetTabNo - RefreshZoom(); - UpdateVarZoom(); if ( bRefMode ) + else + { + RefreshZoom(); + UpdateVarZoom(); + }
Fixed in 24.2 with commit 30662ae380e3d31cc8904fcb1ceeb2592504834d.
Hey Justin L, It seems like your latest commit accidentally referenced: - tdf#347349 when you meant: - tdf#47349 (Notice the extra '3' in beginning!) Unsure if that commit's Bug # needs to be updated for future reference/knowledge/findability.