Tools => Customise Result: Delay of some seconds before dioalog opens Found in Version: 7.0.0.0.alpha1+ (x64) Build ID: 99c337d1d3831ce9d2c7dc1cbff713f4ac49d6ac CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win; Locale: de-DE (de_DE); UI: en-GB Calc: CL No delay in 7.0.0.0.alpha0
it opens within 2 seconds for me in Version: 7.0.0.0.alpha1+ Build ID: 86bc13248c1d9f63b10aac304bdf0361d1dcc47f CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded How long it takes for you? Did you try with a clean profile ?
(In reply to Xisco Faulí from comment #1) > How long it takes for you? 6 seconds > Did you try with a clean profile ? Restart in Safe Mode => 15 seconds the first time and 2 seconds the second time Behaviour in Safe Mode is reproducible
Reported something similar.. 2/3 seconds tends to be normal bug 126043 Version: 7.0.0.0.alpha0+ (x64) Build ID: 97a2c1fc5e376c0c00968f17a0392c6d3a5ed565 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc: threaded
1 second after Restart in safe mode: Factory reseting Version: 7.0.0.0.alpha1 Build ID: 6a03b2a54143a9bc0c6d4c7f1... CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3; Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
Hello Dieter, is this issue still reproducible with a recent master build ?
(In reply to Xisco Faulí from comment #5) > Hello Dieter, > is this issue still reproducible with a recent master build ? in Version: 7.0.0.0.beta1 (x64) Build ID: 94f789cbb33335b4a511c319542c7bdc31ff3b3c it opens with a delay of 3 or 4 seconds (options opens without a delay). So it's better, but not perfect (at least for me)
Very quick in Version: 7.0.2.0.0+ Build ID: 5f305e6792c1c166b2a44a1e5085f42f53db50ea CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded Also very quick in Version: 7.1.0.0.alpha0+ Build ID: e2f4e65a7b8024c00b049eebf0d87637efda7f24 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-US (ro_RO.UTF-8); UI: en-US Calc: threaded
7 seconds in Save Mode and Version: 7.0.1.2 (x64) Build ID: 7cbcfc562f6eb6708b5ff7d7397325de9e764452 CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: default; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: threaded Tests in comment 1, comment 4 and comment 7 are with Linux. So perhaps a problem only in Windows.
It take 3 seconds or so to appear Version: 7.1.0.0.alpha0+ (x64) Build ID: e8b8e7be0b2ad693224cd94062a55610eb69df7e CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL and for me the same with 6.4
(In reply to Telesto from comment #9) > It take 3 seconds or so to appear Not clear to me, if you treat this as a bug or as an expected result
(In reply to Dieter from comment #10) > (In reply to Telesto from comment #9) > > It take 3 seconds or so to appear > > Not clear to me, if you treat this as a bug or as an expected result Some vague memory about creating a bug report for this or being attached to one. A, found it See bug 126043. Which stated to accept they 3 seconds. 7 sec is certainly to long. However I can't reproduce. It might be that simply the same bug which got closed in a different consternation making things worse Or there is a regression; no clue
I tried to bibisect this with 7.0 in Linux. It's always perfect. I think this is a Windows only problem. Someone with Windows should bibisect this for 7.0
I wasn't able to reproduce on windows with the below version initial start up time 3seconds and the subsequent one's were 2scs. Version: 7.0.2.2 (x64) Build ID: 8349ace3c3162073abd90d81fd06dcfb6b36b994 CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
I repro, 6 secs for the first time. Dieter: can you bibisect this? I am currently not able to due to unfinished virtual machine setup. Version: 7.1.0.0.alpha1+ (x64) Build ID: 42a691933429dbb315de2bd7ba2724993c60411f CPU threads: 2; OS: Windows 10.0 Build 19042; UI render: default; VCL: win Locale: fi-FI (fi_FI); UI: en-US Calc: threaded
(In reply to Buovjaga from comment #14) > Dieter: can you bibisect this? I want to limit the time that I spend on LO QA. So I decided not to start with bibisection. Hope you can understand this.
My delay is also ~2 seconds in eg. Writer, less when opened from the start center. Note that the layout of the Customize dialog depends on which editor is open, so that detail should be specified. It seems the bug isn't easy to reproduce. For the record, if someone can reproduce it, with the repo at hand bibisecting the bug should take less than 15 mins (provided there are no complications). Version: 7.0.0.3 (x64) Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL Version: 7.1.0.0.alpha1+ (x64) Build ID: 312a33b7636334f6ce3b6d1702bc5d3e45215601 CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
(In reply to Aron Budea from comment #16) > My delay is also ~2 seconds in eg. Writer, less when opened from the start > center. Note that the layout of the Customize dialog depends on which editor > is open, so that detail should be specified. In Safe mode (the only way to repro normally), it always opens with Menu tab visible.
(In reply to Buovjaga from comment #17) > In Safe mode (the only way to repro normally), it always opens with Menu tab > visible. Which editor, though? Yes, it opens with Menus tab open, but in Writer the tabs are Menus, Toolbars, Notebookbar, Context Menus, Keyboard and Events. In the start center the tabs are Menus, Toolbars, Context Menus and Events. I'd think it matters whether you open from Writer (or another of the editors) or from the start center, because it builds the whole dialog when you open it, and there's much less to build in one case. Btw, it's still 2 seconds for me when opened from Writer in safe mode.
Oh, I didn't understand what you meant by editors. I was using writer.
Delay is the same ballpark in other modules as well, 4,5-6 secs. Only Math and Base are quick, 1 sec.
I also in safe mode with the following result: 5 seconds when opening for the first time in SafeMode; 2,5 seconds when I tried again.
instantly from Start Center and with 2 sec delay in Writer in Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: a9cc066a86c6bd3423c5802c5a4eded55a50c754 CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: ru-RU Calc: CL
Summary says 'the first time' but I experience that it takes about 9-10 seconds for the first time from a document and thereafter about 5 seconds for each following time. From the Start Center, about 3 seconds. (in contrast, Tools>Options opens immediately) Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 7ac19fbce8a35f559eebb879cd0f232bfc95e703 CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: da-DK (da_DK); UI: pt-BR Calc: CL
No repro for me in Win 7, 2 secs. Not sure why it's open, but at least it needs a summary.
*** Bug 147904 has been marked as a duplicate of this bug. ***
No delay in Version: 7.4.0.0.alpha1+ (x64) / LibreOffice Community Build ID: bbec710bd25fc5da27636cde73fe4ab23c76904f CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: win Locale: cs-CZ (cs_CZ); UI: en-GB Calc: CL Could you retest in today daily?
Dealy of around 2 seconds with Version: 7.4.0.0.alpha1 (x64) / LibreOffice Community Build ID: b871abad383583f02eb49c7e49aeae01f6941072 CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL So 2 seconds semms to be the time, that is reproducible for some people here and this is slower than opening other dialogs
Dear Dieter, 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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug