Bug 126683 - calc libreoffice basic 6.2.5.2 does not wait answer after dispatcher.executeDispatch(document, ".uno:Paste", "", 0, Array())
Summary: calc libreoffice basic 6.2.5.2 does not wait answer after dispatcher.executeD...
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: BASIC (show other bugs)
Version:
(earliest affected)
6.2.5.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Regressions-Dialog-Tunneling
  Show dependency treegraph
 
Reported: 2019-08-03 07:05 UTC by factor23
Modified: 2023-05-25 14:12 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description factor23 2019-08-03 07:05:50 UTC
Description:
This problem occurs with both portable and not portable windows version 

It does not ooccur with portable version 3.1.0.3

Actual Results:
sub Test
rem ----------------------------------------------------------------------
rem define variables
dim document   as object
dim dispatcher as object
rem ----------------------------------------------------------------------
rem get access to the document
document   = ThisComponent.CurrentController.Frame
dispatcher = createUnoService("com.sun.star.frame.DispatchHelper")

rem ----------------------------------------------------------------------
dispatcher.executeDispatch(document, ".uno:Paste", "", 0, Array())

rem ----------------------------------------------------------------------
dispatcher.executeDispatch(document, ".uno:Print", "", 0, Array())


end sub

Expected Results:
Diplay of csv page import after past
after clic on ok display of the defaut printer


Reproducible: Always


User Profile Reset: No



Additional Info:
Comment 1 factor23 2019-08-03 07:19:16 UTC
Portable 6.2.5.2 version is 32 bits
Non Portable 6.2.5.2 version is 64 bits
Comment 2 factor23 2019-08-03 07:22:15 UTC
Portable version 6.1.0.3 is 32 bits ( from https://portableapps.com/apps/office )
Comment 3 Oliver Brinzing 2019-08-03 18:37:00 UTC
reproducible with:

Version: 6.2.5.2 (x64)
Build-ID: 1ec314fa52f458adc18c4f025c545a4e8b22c159
CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; 
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Calc: 

but not with LO 6.1.3.2

steps to reproduce:

- open new spreadsheet

- copy to clipboard:
  AAA;BBB;CCC
  111;222;333

- run macro

-> csv text import and print dialog open at same time, print dialog is modal
Comment 4 Oliver Brinzing 2019-08-04 08:18:14 UTC
seems to have started with:

https://gerrit.libreoffice.org/plugins/gitiles/core/+/9233b1549bd7198a6f367b5950352d93b07b2997

commit 9233b1549bd7198a6f367b5950352d93b07b2997	[log]
author	Marco Cecchetti <marco.cecchetti@collabora.com>	
Fri Apr 27 16:45:05 2018 +0200
committer Marco Cecchetti <mrcekets@gmail.com>	
Mon May 28 18:36:42 2018 +0200
tree 8fcf3cc5b2126a6ae5dd0833ada5cd546b05a3b4
parent e99cb63b7d76ce02d0d9cdf13bf5e19e936ad035 [diff]

lok: sc: tunneling the ascii import dialog on paste action

Modified CreateScImportAsciiDlg signature so that we are able to pass
a pointer to a dialog parent window to ScImportAsciiDlg.

Now the execution of the ScImportAsciiDlg dialog in
ScViewFunc::PasteDataFormat is asynchronous, both for lok and desktop
case. In order to achieve this result it has been needed to modify the
lifespan of some objects previously local to PasteDataFormat.
[...]

$ git bisect log
# bad: [35a87a66cfc6dfb661f6fed49fb32c081dd26bc7] source d250c94d78ac7e79753aa30f869db919b01fc450
# good: [b0a56ec98b1368cb5e3e531e0b3f69565af91609] source 3a801799536e6870f2fb111b1cc00b9575a35a39
git bisect start 'master' 'oldest'
# bad: [7f7b05d44d7d7f13cc9c865963a72e555b516b3d] source 1b88de0a07180661c4d5d6706247d546d06bc983
git bisect bad 7f7b05d44d7d7f13cc9c865963a72e555b516b3d
# bad: [893206f564fd73cf737962011484821c90765fd7] source a97411b061a382dc09423d04c633dc9b7d24a737
git bisect bad 893206f564fd73cf737962011484821c90765fd7
# bad: [7ecb380bc34202f7f8075c0829648fed3e2f543d] source 3689c9c67084b6fbf8938f7d7dc4c2a4981831aa
git bisect bad 7ecb380bc34202f7f8075c0829648fed3e2f543d
# bad: [64201e5b66a7b766a59f2234f33f4dbcb8c00ddd] source 99bbed5cd87af8ff1b7e3d197d937fb17af021e6
git bisect bad 64201e5b66a7b766a59f2234f33f4dbcb8c00ddd
# bad: [b606ed8743bf101a663500d34105973bb63fed1d] source b83ec344f914ec6571d6d53b1ea7d0924db7a6a4
git bisect bad b606ed8743bf101a663500d34105973bb63fed1d
# bad: [304f68bc9b6ec9aef58ff91bd2aadf24fe3a7ead] source 46ac529c44d513c31942f13dd5b40f3e5d7c363f
git bisect bad 304f68bc9b6ec9aef58ff91bd2aadf24fe3a7ead
# good: [0e76155ceb3859f146f8318bbd1bd74195d1fe3e] source 9aff9f22adf20aa0c00663648d1875e325b24d42
git bisect good 0e76155ceb3859f146f8318bbd1bd74195d1fe3e
# bad: [02bdff281721318628794f67c780dfde11f37eb8] source ebfb0d3950a8723e24baa330b80a0a560e381639
git bisect bad 02bdff281721318628794f67c780dfde11f37eb8
# good: [73e1d2771a402c9cf0580bbac12bb66bde57a2c1] source eccf771815eefb826f5bb8597277020ec297edf1
git bisect good 73e1d2771a402c9cf0580bbac12bb66bde57a2c1
# bad: [008b3a8a7befd3dd76544d466dbeec875a04cf8a] source 54ddc4ff4c2ff7e8b2c502d6b475cfdc9b8e3cec
git bisect bad 008b3a8a7befd3dd76544d466dbeec875a04cf8a
# good: [aab208962dc4a4eccb17bf47228f7789e22e986c] source 91e6174a088b8c722e8c6d3482c1ae9a6818a7c5
git bisect good aab208962dc4a4eccb17bf47228f7789e22e986c
# bad: [d6b2be0fa9e373ba5b1924451bfd73a3a321dd31] source 9233b1549bd7198a6f367b5950352d93b07b2997
git bisect bad d6b2be0fa9e373ba5b1924451bfd73a3a321dd31
# good: [566994655ff262cb5c16bbce7d3d53e0aa10655e] source e99cb63b7d76ce02d0d9cdf13bf5e19e936ad035
git bisect good 566994655ff262cb5c16bbce7d3d53e0aa10655e
# first bad commit: [d6b2be0fa9e373ba5b1924451bfd73a3a321dd31] source 9233b1549bd7198a6f367b5950352d93b07b2997
Comment 5 QA Administrators 2022-04-20 03:37:01 UTC Comment hidden (obsolete, spam)
Comment 6 Samuel Mehrbrodt (allotropia) 2023-05-25 14:12:04 UTC
These internal LO dialogs surely can be called via UNO API, but they are not part of the API that we guarantee API stability for.

So in this case (and it will probably be the same for most of the dialogs), the change to async was intentional and, even if it resulted in a change of behavior, it is not a bug.