Summary: | CALC becomes unstable depending upon the manner in which a block of assorted fonts is changed | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Colin <that.man.colin> |
Component: | Calc | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | ilmari.lauhakangas |
Priority: | medium | ||
Version: | 7.4.6.2 release | ||
Hardware: | All | ||
OS: | Windows (All) | ||
Whiteboard: | |||
Crash report or crash signature: | Regression By: | ||
Attachments: | Sample LO CALC |
Description
Colin
2023-03-20 17:05:59 UTC
Created attachment 186097 [details]
Sample LO CALC
Update on the trigger mechanism: I rolled back LO and the issue persisted. I can run other LO files whilst the culprit is misbehaving and they process at normal speed. I recovered last night's file and it worked fine the first time I tried the block font change. I exited without saving and loaded again but this time it failed the moment I tried the block font change. Clearly, I must have done something different and have now established that it is the manner in which the block change is initiated that causes the issue. If the block is selected and there is a selection of fonts then the font name box is blank. If the font name is partially typed and the font dropdown is opened and the font is selected from those presented then it fails. However, If the block is selected and the font dropdown is directly opened and scrolled down to the font and the font is selected it works. (In reply to Colin from comment #2) > Update on the trigger mechanism: As the cause has become more definitive I have changed the tagline to reflect the new reality. Feel free to ignore most of the initial report. I'll let one of you "big boys" decide whether the first comment should even be hidden as it's now mostly irrelevant. Sorry it was so verbose, I was trying to demonstrate that it must be a new bug associated with this release and it proved to be a minor variation in my actions exposing a pre-existing feature. I selected AD6:AD7 and tried, but no problem on Windows or Linux. I did notice a small issue and created bug 154680 Arch Linux 64-bit, X11 Version: 7.5.2.2 (X86_64) / LibreOffice Community Build ID: 50(Build:2) CPU threads: 8; OS: Linux 6.2; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US 7.5.2-1 Calc: CL threaded (In reply to Buovjaga from comment #4) > I selected AD6:AD7 and tried, but no problem on Windows or Linux. > > I did notice a small issue and created bug 154680 > Arch Linux 64-bit, X11 > Version: 7.5.2.2 (X86_64) / LibreOffice Community > Build ID: 50(Build:2) > CPU threads: 8; OS: Linux 6.2; UI render: default; VCL: kf5 (cairo+xcb) > Locale: fi-FI (fi_FI.UTF-8); UI: en-US > 7.5.2-1 > Calc: CL threaded Perhaps the issue you have identified is an earlier stage of the extended operations I performed. Have you verified it using Windows 7.4.6.2 AND more importantly, allowed LO to perform a couple of autosaves BEFORE attempting to change the font? It may even be worthwhile creating a few anagrams yourself. It doesn't matter if you "copy" some existing solutions either into the correct columns or any of the other columns. If you replicate words in the correct columns and then sort ascending or descending with that column's autosfilter it will invoke more of the error checking. Just about anything to ensure LO has time to perform a couple of autosaves. As I advised - the malfunction occurred after it would have performed a couple of autosaves and before the attempted block font change. (In reply to Colin from comment #5) > Have you verified it using Windows 7.4.6.2 AND more importantly, allowed LO > to perform a couple of autosaves BEFORE attempting to change the font? No. (In reply to Buovjaga from comment #6) > (In reply to Colin from comment #5) > > Have you verified it using Windows 7.4.6.2 AND more importantly, allowed LO > > to perform a couple of autosaves BEFORE attempting to change the font? > > No. I just tried both this and your newer bug report. This still fails. What is apparent is that the font family on AD6:AD7 is Liberation sans - same font, same cut and it offers Liberation serif. However, the font on the selection I defined is the same family but both sans & serif cuts are used. It appears part of the trigger for the "freeze" and enforced closure is the fact that two different font cuts are selected and the expectation is that the selected font - however it is selected - will impose itself upon all the cells in the selection. (In reply to Colin from comment #7) > (In reply to Buovjaga from comment #6) > > (In reply to Colin from comment #5) > > > Have you verified it using Windows 7.4.6.2 AND more importantly, allowed LO > > > to perform a couple of autosaves BEFORE attempting to change the font? > > > > No. > > I just tried both this and your newer bug report. > > This still fails. > > What is apparent is that the font family on AD6:AD7 is Liberation sans - > same font, same cut and it offers Liberation serif. However, the font on the > selection I defined is the same family but both sans & serif cuts are used. Ignore that, alternate cuts on AD6:AD7 as in the larger DI11:DI27 - my bad |