Steps to reproduce: 1. Open Calc 2. Format - Cells 3. Switch to another tab -> it takes ~20 seconds until the new tab is displayed Reproduced in Version: 6.2.0.0.beta1+ Build ID: 01fea181faf92a3498370460d3db2254da11c3e2 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-6-2&id=3c11aa745cc78f1bde4efacccb22fa818df825c7 author Caolán McNamara <caolanm@redhat.com> 2018-09-25 12:30:21 +0100 committer Caolán McNamara <caolanm@redhat.com> 2018-09-28 15:35:22 +0200 commit 3c11aa745cc78f1bde4efacccb22fa818df825c7 (patch) tree 09135c2ec9f77b09d371418476a5b6fd6acc54d0 parent a98058199410bdb183acd0ec5e7899ea4baf6c5a (diff) weld ScAttrDlg Bisected with: bibisect-linux64-6.2 Adding Cc: to Caolán McNamara
it takes no discernible time for me to switch tabs. In writer does format->character show the same problem ?, or is it specific to calc's format cell ?
I see the same behaviour with the table's number format dialog in writer STR: 1. Open writer 2. Insert a table 3. Context menu - Number format but the bisection points me to https://cgit.freedesktop.org/libreoffice/core/commit/?id=bbeeedbbfa0b7a0d1461c5ff703721bce1b7f80a Maybe it's only reproducible with GTK 3.18.9
I guess then it must be the language dropdown as that the thing that has the most entries in it in that page
I wonder if the fix for bug 121520 makes a difference to this
(In reply to Caolán McNamara from comment #5) > I wonder if the fix for bug 121520 makes a difference to this no significant improvement in Version: 6.3.0.0.alpha0+ Build ID: 0ad2302cf6787cacbbaca081a890a0e356a55297 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded
sample the backtrace when its slow, and see if its stuck in some particular place, e.g. run it under gdb, when it goes into super slow mode, ctrl+c and get a bt, cont, wait a bit, ctrl+c again and see if its about the same bt and if so attach it here
(In reply to Caolán McNamara from comment #7) > sample the backtrace when its slow, and see if its stuck in some particular > place, e.g. run it under gdb, when it goes into super slow mode, ctrl+c and > get a bt, cont, wait a bit, ctrl+c again and see if its about the same bt > and if so attach it here I believe the root cause might be the same as in bug 122168. Anyway, I'll try what you're mentioning above when I have a bit of time...
I upgraded my Linux distro this morning. Now I have GTK3 3.22 and the problem went away. OTOH, I had the same problems sometimes with Firefox. Probably something wrong with my config. Closing as RESOLVED WONTFIX