Created attachment 172591 [details] Testdoc from sc/qa/uitest/data/chartWithDotInSheetName.ods This is created from the test in https://git.libreoffice.org/core/+/752a6d58a440e2cb84e0f84d3e12dd52efd016eb. 1. Open attached document, check that its chart's data series' values are like "$'Sheet.1'.$B$12:$B$18". 2. On the sheet, select all (Ctrl+A), can copy (Ctrl+C). 3. Close the doc (not the application), and create a new spreadsheet. 4. In the new spreadsheet, rename the first sheet to "Sheet.1" (not really necessary, but I'm just following the existing unit test). 5. Paste (Ctrl+V) 6. Inspect the pasted chart's data series. Expected: the series are like "$'Sheet.1'.$B$12:$B$18". Actual: they are like "'file:///D:/Documents/Sheet.1'#$Sheet1.$B$12:$B$18". I assume this works as expected on Linux (the unit test likely runs on linus in our CI). But this fails on Windows, with both Version: 7.1.4.1 (x64) / LibreOffice Community Build ID: f67b1ddedeb24fca1c5938e7cebfab73d708b35b CPU threads: 12; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: threaded and current master Version: 7.2.0.0.alpha1+ (x64) / LibreOffice Community Build ID: 027c7b411389127d77a271e53922edb4d7095a2e CPU threads: 12; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL.
Works fine with Version 3.6.0.4 (Build ID: 932b512) Fails with Version 4.0.0.3 (Build ID: 7545bee9c2a0782548772a21bc84a9dcc583b89)
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/8d98dd8b3896c14af057e90e3a327172a9262e03 tdf#142635: skip UITest for now It will be available in 7.2.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.
Looks there are several reports that at least looks very similar https://bugs.documentfoundation.org/buglist.cgi?quicksearch=copy%20sheet%20chart&list_id=1316194
I hope that it could be bibisected using a 4-0 repo *on Linux*, since commit https://git.libreoffice.org/core/+/752a6d58a440e2cb84e0f84d3e12dd52efd016eb mentions that it was fixed on Linux lately.
(In reply to Mike Kaganski from comment #0) > 6. Inspect the pasted chart's data series. Are the data series the parameters shown in the Data Ranges dialog on the Data Series tab? They seem fine here even in Windows.
(In reply to Aron Budea from comment #5) > (In reply to Mike Kaganski from comment #0) > > 6. Inspect the pasted chart's data series. > Are the data series the parameters shown in the Data Ranges dialog on the > Data Series tab? Exactly. > They seem fine here even in Windows. Interesting. Could it be locale-dependent maybe?
(In reply to Mike Kaganski from comment #6) > Interesting. Could it be locale-dependent maybe? OTOH, unlikely it's LibreOffice locale: the unit testing uses a fixed en-US locale, and I caught the problem when the unit test that I now disabled was failing locally. Maybe system locale then? But despite I have a localized (Russian) Windows, I use a en-US MUI on it, so ... confusing.
Moving to NEW
Xisco, did you reproduce this? I couldn't in Windows 7. So it's not clear if anybody reproduced and why New. I see that there was some issue in 7.2.0 as chart wouldn't paste, but seems OK in 7.4+.
Created attachment 177645 [details] Screencast on 7.4 pre-alpha Still repro using Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 25298b632f31b02b664c72fac91ae77d1531a9db CPU threads: 12; OS: Windows 10.0 Build 19044; UI render: default; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: threaded
Still no repro here in a 7.4 debug build. Based on the screencast the difference seems to be that in your case a "D:\Documents\" prefix is added to the pasted range references that doesn't happen in mine.
No problem with: Version: 7.1.8.1 (x64) / LibreOffice Community Build ID: e1f30c802c3269a1d052614453f260e49458c82c CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: win Calc: CL - Locale: es-MX (es_ES); UI: en-US - Locale: es-MX (es_ES); UI: es-ES - Locale: ru-RU (es_ES); UI: en-US I reseted my user profile a few days ago.
(In reply to LeroyG from comment #12) > No problem with: > > Version: 7.1.8.1 (x64) / LibreOffice Community > Build ID: e1f30c802c3269a1d052614453f260e49458c82c > CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: > win > Calc: CL > > - Locale: es-MX (es_ES); UI: en-US > - Locale: es-MX (es_ES); UI: es-ES > - Locale: ru-RU (es_ES); UI: en-US > > I reseted my user profile a few days ago. @Mike Kaganski, do you still reproduce this on your end ?
(In reply to Xisco Faulí from comment #13) > > No problem with: > > > > Version: 7.1.8.1 (x64) / LibreOffice Community (In reply to Mike Kaganski from comment #10) > Still repro using Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community "No repro with 7.1" is not a reason to recheck after 7.4 was confirmed to have the issue ;) However: I do see the problem with current master. Could someone please show a screencast of this *working*? I hope to notice something important that could hint at what is the crucial difference. Thanks!
Do not need to close the document and create a new one; just copy, then add a sheet to the left of the original, and the data becomes linked to the original data cells. See https://ask.libreoffice.org/t/copy-tab-in-calc-with-charts-and-have-the-charts-link-to-data-in-the-new-tab/77342/7?u=leroyg Not reproducible with version 7.2.3.2 on Linux.
The problem happens in lcl_ScAddress_Parse_OOo (sc/source/core/tool/address.cxx) during *copy* to clipboard. The 'if (!bExtDoc && !rDoc.GetTable( aTab, nTab ))' branch executes (because rDoc doesn't happen to have the table (sheet) with the "Sheet.1" name), and then for the testcase from comment 0, the 'if (n > 0 && aTab.getLength() - n <= 4)' executes, as if ".1" was a file extension, making the import code think that it was an external reference (for names without a dot, or with more than 4 characters after the dot, it would be different - likely manifesting as comment 15 describes). The copy code has at least three ScDocument live on the call stack: the original document, the clipboard document, and some temporary document used in Chart-specific code here; the latter has no correct table name (yet?). I suppose that the range a2e6f31c6f90e446d1462e7c80f6b1317f7825bc .. b9652803096b68a33702601aac52e78c8a4250c6 could change something that the platform-specific clipboard code now could do something with the Chart-specific ScDocument so that it already has correct table names when this code executes, while Windows-specific code does that in a different order. However, the multiple "works here on Windows" responses look confusing, given how consistently reproduce the problem on Windows on my system (and the test failing for me locally - that I disabled in the commit mentioned in comment 2 - at least worked fine on Jenkins Windows builders). Eike: do you have an idea where could I look at to find the problem?
(In reply to Mike Kaganski from comment #16) > the platform-specific clipboard code now could do something with the > Chart-specific ScDocument so that it already has correct table names when > this code executes, while Windows-specific code does that in a different > order. OTOH, debugging on Linux, I see the same hits inside the 'if (!bExtDoc && !rDoc.GetTable( aTab, nTab ))' branch - so there's likely something happening *on paste* to undo this incorrect reference created on copy - that executes in some circumstances (on Linux; on some Windows), but not in other circumstances ... Yet I still think that copy code is the primary suspect here, there should not be a reason to generate such invalid references in the first place.
That portion of code basically was added with 296baa2fb6dd4150a7855114093a9703cdc18b09 already (a larger patch incorporated from ooo-build) and to me looks plain wrong from a first glance. If bExtDoc==false at that place it means that earlier on a 'filename'# was not parsed at the beginning nor pExtInfo->mbExternal was set, thus it is not an external document in the OOo|ODF notation. I'll dig into that for that part.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/fe687d1b8f5305edfb167152a4fb19ffa20c5404 Related: tdf#142635 Remove address parsing failback code It will be available in 7.4.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.
@Mike: Please check with that patch whether the behaviour changed on Windows.
(In reply to Eike Rathke from comment #20) Thank you Eike! The patch has definitely made a difference - but not fixed it yet. Now the pasted chart has an internal data table, resembling what happened around OOo/LO 3.3.0. If I avoid setting nBits to zero at line 1232 [1], then it works "as expected", because it just ignores the "no such sheet" problem. So IMO there's still a problem that the ScDocument used in the Chart export/import is not initialized properly *in advance* (maybe even it should not be created, but reused, when appropriate). Let me paste the call stack of the first break on line 1232 [1] when selecting all and Ctrl+C on my Windows system: > [ 0] sclo.dll!lcl_ScAddress_Parse_OOo(const char16_t * p, const ScDocument & rDoc, ScAddress & rAddr, ScRefFlags & rRawRes, ScAddress::ExternalInfo * pExtInfo, ScRange * pRange, long * pSheetEndPos, const rtl::OUString * pErrRef) Line 1232 C++ > [ 1] sclo.dll!lcl_ScAddress_Parse(const char16_t * p, const ScDocument & rDoc, ScAddress & rAddr, const ScAddress::Details & rDetails, ScAddress::ExternalInfo * pExtInfo, const com::sun::star::uno::Sequence<com::sun::star::sheet::ExternalLinkInfo> * pExternalLinks, long * pSheetEndPos, const rtl::OUString * pErrRef) Line 1487 C++ > [ 2] sclo.dll!ScAddress::Parse(const rtl::OUString & r, const ScDocument & rDoc, const ScAddress::Details & rDetails, ScAddress::ExternalInfo * pExtInfo, const com::sun::star::uno::Sequence<com::sun::star::sheet::ExternalLinkInfo> * pExternalLinks, long * pSheetEndPos, const rtl::OUString * pErrRef) Line 1545 C++ > [ 3] sclo.dll!ScRangeStringConverter::GetStringFromXMLRangeString(rtl::OUString & rString, const rtl::OUString & rXMLRange, const ScDocument & rDoc) Line 857 C++ > [ 4] sclo.dll!ScChart2DataProvider::convertRangeFromXML(const rtl::OUString & sXMLRange) Line 2291 C++ > [ 5] xolo.dll!`anonymous namespace'::lcl_ConvertRange(const rtl::OUString & rRange, const com::sun::star::uno::Reference<com::sun::star::chart2::XChartDocument> & xDoc) Line 77 C++ > [ 6] xolo.dll!SchXMLPlotAreaContext::startFastElement(long __formal, const com::sun::star::uno::Reference<com::sun::star::xml::sax::XFastAttributeList> & xAttrList) Line 234 C++ > [ 7] xolo.dll!SvXMLImport::startFastElement(long Element, const com::sun::star::uno::Reference<com::sun::star::xml::sax::XFastAttributeList> & Attribs) Line 815 C++ > [ 8] expwraplo.dll!`anonymous namespace'::Entity::startElement(const `anonymous-namespace'::Event * pEvent) Line 471 C++ > [ 9] expwraplo.dll!sax_fastparser::FastSaxParserImpl::callbackStartElement(const unsigned char * localName, const unsigned char * prefix, const unsigned char * URI, int numNamespaces, const unsigned char * * namespaces, int numAttributes, const unsigned char * * attributes) Line 1302 C++ > [10] expwraplo.dll!call_callbackStartElement(void * userData, const unsigned char * localName, const unsigned char * prefix, const unsigned char * URI, int numNamespaces, const unsigned char * * namespaces, int numAttributes, int __formal, const unsigned char * * attributes) Line 332 C++ > [11] libxml2.dll!xmlParseStartTag2(_xmlParserCtxt * ctxt, const unsigned char * * pref, const unsigned char * * URI, int * tlen) Line 9670 C > [12] libxml2.dll!xmlParseTryOrFinish(_xmlParserCtxt * ctxt, int terminate) Line 11456 C > [13] libxml2.dll!xmlParseChunk(_xmlParserCtxt * ctxt, const char * chunk, int size, int terminate) Line 12351 C > [14] expwraplo.dll!sax_fastparser::FastSaxParserImpl::parse() Line 1097 C++ > [15] expwraplo.dll!sax_fastparser::FastSaxParserImpl::parseStream(const com::sun::star::xml::sax::InputSource & rStructSource) Line 906 C++ > [16] expwraplo.dll!sax_fastparser::FastSaxParser::parseStream(const com::sun::star::xml::sax::InputSource & aInputSource) Line 1482 C++ > [17] xolo.dll!SvXMLImport::parseStream(const com::sun::star::xml::sax::InputSource & aInputSource) Line 512 C++ > [18] chartcorelo.dll!chart::XMLFilter::impl_ImportStream(const rtl::OUString & rStreamName, const rtl::OUString & rServiceName, const com::sun::star::uno::Reference<com::sun::star::embed::XStorage> & xStorage, const com::sun::star::uno::Reference<com::sun::star::lang::XMultiComponentFactory> & xFactory, const com::sun::star::uno::Reference<com::sun::star::document::XGraphicStorageHandler> & xGraphicStorageHandler, const com::sun::star::uno::Reference<com::sun::star::beans::XPropertySet> & xImportInfo) Line 469 C++ > [19] chartcorelo.dll!chart::XMLFilter::impl_Import(const com::sun::star::uno::Reference<com::sun::star::lang::XComponent> & xDocumentComp, const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & rMediaDescriptor) Line 374 C++ > [20] chartcorelo.dll!chart::XMLFilter::filter(const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & aDescriptor) Line 222 C++ > [21] chartcorelo.dll!chart::ChartModel::impl_load(const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & rMediaDescriptor, const com::sun::star::uno::Reference<com::sun::star::embed::XStorage> & xStorage) Line 562 C++ > [22] chartcorelo.dll!chart::ChartModel::loadFromStorage(const com::sun::star::uno::Reference<com::sun::star::embed::XStorage> & xStorage, const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & rMediaDescriptor) Line 755 C++ > [23] embobj.dll!OCommonEmbeddedObject::LoadDocumentFromStorage_Impl() Line 549 C++ > [24] embobj.dll!OCommonEmbeddedObject::SwitchStateTo_Impl(long nNextState) Line 191 C++ > [25] embobj.dll!OCommonEmbeddedObject::changeState(long nNewState) Line 459 C++ > [26] svtlo.dll!svt::EmbeddedObjectRef::TryRunningState(const com::sun::star::uno::Reference<com::sun::star::embed::XEmbeddedObject> & xEmbObj) Line 819 C++ > [27] sclo.dll!ScChartHelper::AddRangesIfProtectedChart(std::vector<ScRangeList,std::allocator<ScRangeList>> & rRangesVector, const ScDocument & rDocument, SdrObject * pObject) Line 298 C++ > [28] sclo.dll!ScChartHelper::FillProtectedChartRangesVector(std::vector<ScRangeList,std::allocator<ScRangeList>> & rRangesVector, const ScDocument & rDocument, const SdrPage * pPage) Line 333 C++ > [29] sclo.dll!ScViewFunc::CopyToClipSingleRange(ScDocument * pClipDoc, const ScRangeList & rRanges, bool bCut, bool bIncludeObjects) Line 277 C++ > [30] sclo.dll!ScViewFunc::CopyToClip(ScDocument * pClipDoc, const ScRangeList & rRanges, bool bCut, bool bApi, bool bIncludeObjects, bool bStopEdit) Line 212 C++ > [31] sclo.dll!ScViewFunc::CopyToClip(ScDocument * pClipDoc, bool bCut, bool bApi, bool bIncludeObjects, bool bStopEdit) Line 178 C++ > [32] sclo.dll!ScCellShell::ExecuteEdit(SfxRequest & rReq) Line 1350 C++ > [33] sclo.dll!SfxStubScCellShellExecuteEdit(SfxShell * pShell, SfxRequest & rReq) Line 7541 C++ > [34] sfxlo.dll!SfxDispatcher::Call_Impl(SfxShell & rShell, const SfxSlot & rSlot, SfxRequest & rReq, bool bRecord) Line 257 C++ > [35] sfxlo.dll!SfxDispatcher::Execute_(SfxShell & rShell, const SfxSlot & rSlot, SfxRequest & rReq, SfxCallMode eCallMode) Line 753 C++ > [36] sfxlo.dll!SfxBindings::Execute_Impl(SfxRequest & aReq, const SfxSlot * pSlot, SfxShell * pShell) Line 1061 C++ > [37] sfxlo.dll!SfxDispatchController_Impl::dispatch(const com::sun::star::util::URL & aURL, const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & aArgs, const com::sun::star::uno::Reference<com::sun::star::frame::XDispatchResultListener> & rListener) Line 701 C++ > [38] sfxlo.dll!SfxOfficeDispatch::dispatch(const com::sun::star::util::URL & aURL, const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & aArgs) Line 262 C++ > [39] svtlo.dll!svt::`anonymous namespace'::AsyncAccelExec::impl_ts_asyncCallback(LinkParamNone * __formal) Line 480 C++ > [40] svtlo.dll!svt::`anonymous namespace'::AsyncAccelExec::LinkStubimpl_ts_asyncCallback(void * instance, LinkParamNone * data) Line 472 C++ > [41] vcllo.dll!Link<LinkParamNone *,void>::Call(LinkParamNone * data) Line 111 C++ > [42] vcllo.dll!vcl::EventPoster::DoEvent_Impl(void * __formal) Line 53 C++ > [43] vcllo.dll!vcl::EventPoster::LinkStubDoEvent_Impl(void * instance, void * data) Line 48 C++ > [44] vcllo.dll!Link<void *,void>::Call(void * data) Line 111 C++ > [45] vcllo.dll!ImplHandleUserEvent(ImplSVEvent * pSVEvent) Line 2232 C++ > [46] vcllo.dll!ImplWindowFrameProc(vcl::Window * _pWindow, SalEvent nEvent, const void * pEvent) Line 2800 C++ > [47] vcllo.dll!SalFrame::CallCallback(SalEvent nEvent, const void * pEvent) Line 308 C++ > [48] vclplug_winlo.dll!ImplHandleUserEvent(HWND__ * hWnd, __int64 lParam) Line 4214 C++ > [49] vclplug_winlo.dll!SalFrameWndProc(HWND__ * hWnd, unsigned int nMsg, unsigned __int64 wParam, __int64 lParam, bool & rDef) Line 5865 C++ > [50] vclplug_winlo.dll!SalFrameWndProcW(HWND__ * hWnd, unsigned int nMsg, unsigned __int64 wParam, __int64 lParam) Line 5972 C++ > [51] user32.dll!UserCallWinProcCheckWow() Unknown > [52] user32.dll!DispatchMessageWorker() Unknown > [53] vclplug_winlo.dll!ImplSalDispatchMessage(const tagMSG * pMsg) Line 475 C++ > [54] vclplug_winlo.dll!ImplSalYield(bool bWait, bool bHandleAllCurrentEvents) Line 506 C++ > [55] vclplug_winlo.dll!WinSalInstance::DoYield(bool bWait, bool bHandleAllCurrentEvents) Line 581 C++ > [56] vcllo.dll!ImplYield(bool i_bWait, bool i_bAllEvents) Line 474 C++ > [57] vcllo.dll!Application::Yield() Line 559 C++ > [58] vcllo.dll!Application::Execute() Line 452 C++ > [59] sofficeapp.dll!desktop::Desktop::Main() Line 1600 C++ > [60] vcllo.dll!ImplSVMain() Line 202 C++ > [61] vcllo.dll!SVMain() Line 235 C++ > [62] sofficeapp.dll!soffice_main() Line 94 C++ > [63] soffice.bin!sal_main() Line 51 C > [64] soffice.bin!main(int argc, char * * argv) Line 49 C > [65] soffice.bin!invoke_main() Line 79 C++ > [66] soffice.bin!__scrt_common_main_seh() Line 288 C++ > [67] soffice.bin!__scrt_common_main() Line 331 C++ > [68] soffice.bin!mainCRTStartup(void * __formal) Line 17 C++ > [69] kernel32.dll!00007fffb0bb7034() Unknown > [70] ntdll.dll!00007fffb10c2651() Unknown At frame 0, rDoc has empty maTabNames, and its maTabs has a single element with aName and aCodeName equal to "Sheet1", and aUpperName "SHEET1". It comes from ScChart2DataProvider::m_pDocument (frame 4), which in turn comes from chart::ChartModel::m_xDataProvider (frame 5), possibly created when xDocument is created in frame 23. At the same time, frame 27 has rDocument with empty maTabNames, but the single maTabs element has aName equal to "Sheet.1", and aUpperName "SHEET.1" (aCodeName is equal to "Sheet1"). It comes from frame 29, where rDoc is obtained from GetViewData().GetDocument() - so it likely represents the current active document from which we are copying. And the same frame 29 has pClipDoc, which has a single "Sheet.1" in maTabNames, and a single element in maTabs with aName and aCodeName equal to "Sheet.1", and empty aUpperName. It is created right there, in the ScViewFunc::CopyToClipSingleRange (the caller sends nullptr). I see it, but I have absolutely no idea what to do with this all. I suppose that either the lower frames (0-23) should use pClipDoc from frame 29, or they should prepare their own document from rDoc from frame 29 ... so something needs to be passed from frame 29 (27?) down to frame 23. Or I may misunderstand it all completely ... it really looks too complicated, how the copy to clipboard is implemented, with the intermediate fastparser stage :( Note that it's same when you put breakpoint to that line on Linux (even though the end result differs), so possibly it's possible to debug there. [1] https://opengrok.libreoffice.org/xref/core/sc/source/core/tool/address.cxx?r=fe687d1b#1232
(In reply to Mike Kaganski from comment #21) > And the same frame 29 has pClipDoc, which has a single "Sheet.1" in > maTabNames, and a single element in maTabs with aName and aCodeName equal to > "Sheet.1", and empty aUpperName. It is created right there, in the > ScViewFunc::CopyToClipSingleRange (the caller sends nullptr). In fact. the document used in frame 0 is created also there in frame 29, right after the pClipDoc is created: if ( bSysClip && bIncludeObjects ) { bool bAnyOle = rDoc.HasOLEObjectsInArea( aRange ); // Update ScGlobal::xDrawClipDocShellRef. ScDrawLayer::SetGlobalDrawPersist( ScTransferObj::SetDrawClipDoc( bAnyOle ) ); } ScTransferObj::SetDrawClipDoc creates a new ScDocShell, which created a new ScDocument (m_aDocument). So maybe the code in frame 29 needs to create the ScDocShell when it needs a pClipDoc, and then pass it to the SetDrawClipDoc to avoid two different documents?
I'm afraid it requires some changes to the ScDocShell, making it only reference the ScDocument, similar to how SwDocShell references SwDoc. Then the sharing of the ScDocument (clip) could be established, and the ScDrawLayer::SetGlobalDrawPersist could be used with the doc shell referring the clip doc successfully.
(In reply to Eike Rathke from comment #18) > That portion of code basically was added with > 296baa2fb6dd4150a7855114093a9703cdc18b09 already (a larger patch > incorporated from ooo-build) and to me looks plain wrong from a first > glance. If bExtDoc==false at that place it means that earlier on a > 'filename'# was not parsed at the beginning nor pExtInfo->mbExternal was > set, thus it is not an external document in the OOo|ODF notation. @Eike: Can you write a quick test for this? This sort of a corner case expectation is not something that people can just understand.
(In reply to Mike Kaganski from comment #16) > (and the test failing for me locally - that I disabled in the commit > mentioned in comment 2 - at least worked fine on Jenkins Windows builders). Hmm, I managed to confuse myself. Of course, Jenkins had never tested that on Windows: that was a UITest, and these are only run by Jenkins on Linux. The test failed for me locally because I ran it manually; so nothing indicates that it has ever worked on Jenkins builders. Still would be very interested to see a screencast of working on Windows, as I asked in comment 14.
Created attachment 180135 [details] Screenshots on 7.4+ Windows
(In reply to Timur from comment #26) Thank you very much Timur!
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5386e561204af47a7a5eac3e56850478980bbc15 Related: tdf#142635 Make ScDocShell reference ScDocument by shared_ptr It will be available in 7.4.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.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/964e2eaae9d32df201574e6f083acc630fed2f1d tdf#142635: use the same ScDocument for clipboard and GlobalDrawPersist It will be available in 7.4.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.