Created attachment 125609 [details] Macrobutton shows the issue
Its a REGRESSION it not happens in LO 4 only LO 5 Our users are confronted with empty Msgboxes , empty Erromessages, and also enmpty Dialogs (xray) Verry hard to reproduce sometimes the box is empty, next time its normal. It happens always when there is a dialog on the screen with a "rendered" image in the screen. But sometimes it happens also with normal Dialogs and no rendered images init. The number of controls affect the behaviour. The rendering of a image is done in the Dialog.peer. oRenderer = createUnoService("com.sun.star.graphic.GraphicRendererVCL") oRenderer.Device = odialog.Peer.createGraphics.Device oRenderer.DestinationRect = sRectan oRenderer.render(oGraphic) The attached document show the bug push the button in the document to open a dialog where the document image is shown for cropping. Then push on the button in the dialig and a EMPTY error messsage will been showed. The same happens with: mssbox "print" output from basic xray dialogs
Confirming behavior reported on windows 10 Pro 64-bit en-US with 5.1.3 release build and current 5.3alpha0+ master. The empty (white background withing frame) dialogs occur with default rendering and with OpenGL rendering. The initial click on the button sometimes results in one initial dialog with text, but the button label text becomes selected--and any additional dialogs open empty. Version: 5.1.3.2 (x64) Build ID: 644e4637d1d8544fd9f56425bd6cec110e49301b CPU Threads: 8; OS Version: Windows 6.19; UI Render: default; Locale: en-US (en_US) Version: 5.3.0.0.alpha0+ (x64) Build ID: 0d66c76fc61c09df17b0a1bebbcc5270df267117 CPU Threads: 8; OS Version: Windows 6.19; UI Render: default; TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2016-06-10_22:23:01 Locale: en-US (en_US)
Couldn't reproduce with: Version: 5.3.0.0.alpha0+ Build ID: 8a70742bf395fc2aab6197f04ddbfbd8ee16f263 CPU Threads: 4; OS Version: Linux 4.5; UI Render: default; Locale: en-US (en_US.UTF-8) and Version: 5.1.3.2 Build ID: 1:5.1.3-2 CPU Threads: 4; OS Version: Linux 4.5; UI Render: default; Locale: tr-TR (en_US.UTF-8)
>> Stuard Indeed when openGL is enabled the first time the msgbox is OK repeating the action gives again empty white boxes an sometimes msgboxes who ares OK. ? >>Muhammet Did you check your openGL settings when making your confirmation with Linux ?
This seems to have begun at the below commit. Adding Cc: to Caolán ; Could you possibly take a look at this one? Thanks 0619a0b9b857e44c35e7a2b79efcbf6985bea146 is the first bad commit commit 0619a0b9b857e44c35e7a2b79efcbf6985bea146 Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Fri Nov 13 18:34:18 2015 -0800 source 82abd23f3ee1900b7579e5a0afa23581d5836f01 author Caolán McNamara <caolanm@redhat.com> 2015-11-12 16:05:44 (GMT) committer Caolán McNamara <caolanm@redhat.com> 2015-11-12 16:06:01 (GMT) commit 82abd23f3ee1900b7579e5a0afa23581d5836f01 (patch) tree 468e69642dedb4f030829ec4e7e530deecf96c65 parent 1ba9d7fd2a7a3e2b4f52ed0f5efdf7df867b9db3 (diff) Resolves: tdf#93317 Modified Document Dialog misses focus on Gtk3
caolanm->raal: That's a window bibisect ? i.e. this is only reproducible under windows ?
(In reply to Caolán McNamara from comment #7) > caolanm->raal: That's a window bibisect ? i.e. this is only reproducible > under windows ? Yes, windows bibisect. Not tested under linux yet, but according to comment 6 looks like win only regression.
(In reply to Caolán McNamara from comment #7) > caolanm->raal: That's a window bibisect ? i.e. this is only reproducible > under windows ? Yes, windows bibisect. Not tested under linux yet, but according to comment 4 looks like win only regression.
If we then assume that 0619a0b9b857e44c35e7a2b79efcbf6985bea146 is at fault I guess the thing to do is to try and fix that original problem differently in a way that leaves windows alone.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1092cc0c75f6d2ab649dd31b1db9f0a9f0944355 Related: tdf#100337 revert x-crossplatform ToTop... It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-5-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=dc4768583bf90f5a1623f2a3724c2458efae3a65&h=libreoffice-5-2 Related: tdf#100337 revert x-crossplatform ToTop... It will be available in 5.2.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I've an alternative solution for the thing that prompted me to add ToTop there. I'd appreciate if someone on windows can test (like the message say) a windows 5.3/5.2 build with this fix in it, and report if it works. If it does I'll backport to 5.1 Lets assume this fixes this for now and mark it as such
fernand->caolanm: Thanks for the fix, i will test as soon i find a dayly build (Windows 32 bit) we are still stuck to 32 because there is no 64 bit native MYSQLconnector :-)
Caolán, i tested with no luck (same behaviour) with a daily build Version: 5.3.0.0.alpha0+ Build ID: bb6acbd0c3e8240c976ed62e04275ec67fa5a61d CPU Threads: 4; OS Version: Windows 6.29; UI Render: GL; TinderBox: Win-x86@42, Branch:master, Time: 2016-06-11_00:27:38 Locale: nl-BE (nl_BE) Maybe tomorow ?
checking git log here commit bb6acbd0c3e8240c976ed62e04275ec67fa5a61d is still before commit 1092cc0c75f6d2ab649dd31b1db9f0a9f0944355 Author: Caolán McNamara <caolanm@redhat.com> Date: Mon Jun 13 14:44:59 2016 +0100 Related: tdf#100337 revert x-crossplatform ToTop... so try again in another 24 hours to see if the next daily makes a difference as that bb6acbd0c3e8240c976ed62e04275ec67fa5a61d build doesn't include this effort yet. Doesn't mean it'll work, but not proved not to work yet.
Version: 5.3.0.0.alpha0+ Build ID: 58959a946c0a412c3f997d8511eacb316626cd42 CPU Threads: 8; OS Version: Windows 6.19; UI Render: default; TinderBox: Win-x86@39, Branch:master, Time: 2016-06-15_12:04:53 Locale: en-US (en_US) With OpenGL disabled believe this now functions as intended. But with OpenGL rendering enabled the empty (white background within frame) dialogs continue.
Fernand-> Stuard Thanks for the testing, For what functionalities do we need to "enable" GL ?
(In reply to Fernand from comment #18) > Fernand-> Stuard > Thanks for the testing, > For what functionalities do we need to "enable" GL ? Fernand, There are few if any things in LibreOffice that require use of OpenGL rendering. Unfortunately it is enabled by default on the Windows builds. The OpenGL rendering unloads document and GUI elements from CPU to graphics processor. When functioning correctly it will enhance visual appearance and for some graphical processes can be orders of magnitude faster. Disabled, your users may see noticeable screen "flicker" as the GUI refreshes under CPU or non-OpenGL graphics processor control. Page scrolling and some of the slide transitions in Impress are accelerated by OpenGL. Some newer desktop environments are very dependent on functioning of OpenGL calls for texturing and font rendering. On Linux it manifests with GTK2 versus the GTK3--GPU drivers must support a wider set of features for GTK3. In Windows there are differences between legacy GDI+ graphics and the DirectWrite graphics calls used with OpenGL. Using default rendering uses the GDI+, using OpenGL rendering uses DirectWrite. And have the same issues regards determining the capabilities of GPU hardware and drivers. So a fair amount of LibreOffice developer effort is going toward making OpenGL functional on OS and Desktops that support it--or "blacklisting" it when hardware/driver combinations suggest OpenGL performance would be lacking.
caolan->VStuart: So according to #3 and #17 we've gone from always white bg to opengl-only always white, right ? So the above commit appears necessary but not sufficient ?
(In reply to Caolán McNamara from comment #20) > caolan->VStuart: So according to #3 and #17 we've gone from always white bg > to opengl-only always white, right ? So the above commit appears necessary > but not sufficient ? Yes that would be my assessment. Seems usable again, but not with OpenGL rendering enabled.
Fernand->Stuard thanks for this important background information. Could we switch between "GL enabled" and "GL not enabled" using the API configuration settings, without restart LO ? Fernand->Caolän can this issue also been fixed for Windows with GL enabled ? Thanks for the work done
on WINDOWS 8.1 pro latest build Version: 5.3.0.0.alpha0+ Build ID: 3ab13873ebb6dc4738be2e2184ee4433a2447c1d CPU Threads: 4; OS Version: Windows 6.29; UI Render: default; TinderBox: Win-x86@39, Branch:master, Time: 2016-06-16_01:48:01 Locale: nl-BE (nl_BE) Strange but we have different results as Stuard has >GL enabled first msgbox OK al the rest not OK >GL Disabled First Megbox OK second always notOK rest ramdom ok and notOK also strange: in the 5.1 (without fix) we have better results (more visible msgboxes) with the GL enabled
>> Caolàn Any news here? Can you please find sometime to make this happen, we are still stuck to 4.0 greetz Fernand
Had a run on Windows 10 Pro 64-bit en-US both with and without OpenGL enabled on both Version: 5.2.1.2 (x64) Build ID: 31dd62db80d4e60af04904455ec9c9219178d620 CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; (and default) Locale: en-US (en_US); Calc: group Version: 5.3.0.0.alpha0+ Build ID: 696e83b663d4f3e00f23947613f9f3916a4dd14d CPU Threads: 8; OS Version: Windows 6.19; UI Render: default; (and GL) TinderBox: Win-x86@42, Branch:master, Time: 2016-09-03_10:21:32 Locale: en-US (en_US); Calc: CL The dialog/message boxes still render with white background with both OpenGL rendering and default rendering, but the OpenGL rendering is still noticeably more frequent as I move the clip box around or resize it and apply. But the fact the layer glitch in the message box is happening in both render engines suggests the issue may not be with OpenGL but the with methods used to compose the dialog/message boxes.
Adding Cc: to Caolán McNamara
Please Can something been done here? It block us to develop with LO as the print box is a vital debug tool. Thanks anyhow
Noel is looking at this...
Created attachment 129223 [details] updated doc current master will complain a lot about basic syntax errors around missing ")" at the end of lines, so I fixed those.
The problematic combination is this: (1) we are inside an Idle when we invoke the second dialog box. (2) When the scheduler goes to run Idles, it picks the one for the first dialog box. But since we are inside that Idle, the Invoke() method just returns. Which means that the second Idle never gets to run, and the second Idle is responsible for painting the second dialog box. The stack trace looks like this: vcllo.dll!ImplSchedulerData::Invoke() Line 49 C++ vcllo.dll!Scheduler::ProcessTaskScheduling(bool bTimerOnly) Line 183 C++ vcllo.dll!Scheduler::CallbackTaskScheduling(bool __formal) Line 170 C++ vcllo.dll!SalTimer::CallCallback(bool idle) Line 55 C++ vcllo.dll!EmitTimerCallback() Line 174 C++ vcllo.dll!SalComWndProc(HWND__ * __formal, unsigned int nMsg, unsigned int wParam, long lParam, int & rDef) Line 739 C++ vcllo.dll!SalComWndProcW(HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam) Line 770 C++ [External Code] [Frames below may be incorrect and/or missing, no symbols loaded for user32.dll] vcllo.dll!ImplSalDispatchMessage(tagMSG * pMsg) Line 575 C++ vcllo.dll!ImplSalYield(bool bWait, bool bHandleAllCurrentEvents) Line 592 C++ vcllo.dll!WinSalInstance::DoYield(bool bWait, bool bHandleAllCurrentEvents, unsigned long nReleased) Line 658 C++ vcllo.dll!ImplYield(bool i_bWait, bool i_bAllEvents, const unsigned long nReleased) Line 506 C++ vcllo.dll!Application::Yield() Line 551 C++ vcllo.dll!Dialog::Execute() Line 910 C++ sblo.dll!SbRtl_MsgBox(StarBASIC * pBasic, SbxArray & rPar, bool bWrite) Line 4614 C++ sblo.dll!SbiStdObject::Notify(SfxBroadcaster & rBC, const SfxHint & rHint) Line 844 C++ svllo.dll!SfxBroadcaster::Broadcast(const SfxHint & rHint) Line 51 C++ sblo.dll!SbxVariable::Broadcast(unsigned long nHintId) Line 193 C++ sblo.dll!SbxValue::SbxValue(const SbxValue & r) Line 63 C++ sblo.dll!SbxVariable::SbxVariable(const SbxVariable & r) Line 77 C++ sblo.dll!SbxMethod::SbxMethod(const SbxMethod & r) Line 872 C++ sblo.dll!SbiRuntime::FindElement(SbxObject * pObj, unsigned long nOp1, unsigned long nOp2, unsigned long nNotFound, bool bLocal, bool bStatic) Line 3523 C++ sblo.dll!SbiRuntime::StepRTL(unsigned long nOp1, unsigned long nOp2) Line 3936 C++ sblo.dll!SbiRuntime::Step() Line 772 C++ sblo.dll!SbModule::Run(SbMethod * pMeth) Line 1144 C++ sblo.dll!SbModule::Notify(SfxBroadcaster & rBC, const SfxHint & rHint) Line 810 C++ svllo.dll!SfxBroadcaster::Broadcast(const SfxHint & rHint) Line 51 C++ sblo.dll!SbMethod::Broadcast(unsigned long nHintId) Line 2135 C++ sblo.dll!SbxValue::SbxValue(const SbxValue & r) Line 63 C++ sblo.dll!SbxVariable::SbxVariable(const SbxVariable & r) Line 77 C++ sblo.dll!SbxMethod::SbxMethod(const SbxMethod & r) Line 872 C++ sblo.dll!SbiRuntime::FindElement(SbxObject * pObj, unsigned long nOp1, unsigned long nOp2, unsigned long nNotFound, bool bLocal, bool bStatic) Line 3523 C++ sblo.dll!SbiRuntime::StepELEM(unsigned long nOp1, unsigned long nOp2) Line 3999 C++ sblo.dll!SbiRuntime::Step() Line 772 C++ sblo.dll!SbModule::Run(SbMethod * pMeth) Line 1144 C++ sblo.dll!SbModule::Notify(SfxBroadcaster & rBC, const SfxHint & rHint) Line 810 C++ svllo.dll!SfxBroadcaster::Broadcast(const SfxHint & rHint) Line 51 C++ sblo.dll!SbMethod::Broadcast(unsigned long nHintId) Line 2135 C++ sblo.dll!SbxValue::Get(SbxValues & rRes) Line 288 C++ sblo.dll!SbMethod::Call(SbxValue * pRet, SbxVariable * pCaller) Line 2091 C++ basprovlo.dll!basprov::BasicScriptImpl::invoke(const com::sun::star::uno::Sequence<com::sun::star::uno::Any> & aParams, com::sun::star::uno::Sequence<short> & aOutParamIndex, com::sun::star::uno::Sequence<com::sun::star::uno::Any> & aOutParam) Line 236 C++ dlgprovlo.dll!dlgprov::DialogSFScriptListenerImpl::firing_impl(const com::sun::star::script::ScriptEvent & aScriptEvent, com::sun::star::uno::Any * pRet) Line 503 C++ dlgprovlo.dll!dlgprov::DialogScriptListenerImpl::firing(const com::sun::star::script::ScriptEvent & aScriptEvent) Line 658 C++ dlgprovlo.dll!dlgprov::DialogAllListenerImpl::firing_impl(const com::sun::star::script::AllEventObject & Event, com::sun::star::uno::Any * pRet) Line 403 C++ dlgprovlo.dll!dlgprov::DialogAllListenerImpl::firing(const com::sun::star::script::AllEventObject & Event) Line 424 C++ evtattlo.dll!comp_EventAttacher::FilterAllListenerImpl::firing(const com::sun::star::script::AllEventObject & Event) Line 456 C++ evtattlo.dll!comp_EventAttacher::InvocationToAllListenerMapper::invoke(const rtl::OUString & FunctionName, const com::sun::star::uno::Sequence<com::sun::star::uno::Any> & Params, com::sun::star::uno::Sequence<short> & __formal, com::sun::star::uno::Sequence<com::sun::star::uno::Any> & __formal) Line 170 C++ msci_uno.dll!`anonymous namespace'::callVirtualMethod(void * pAdjustedThisPtr, long nVtableIndex, void * pRegisterReturn, _typelib_TypeClass eReturnTypeClass, long * pStackLongs, long nStackLongs) Line 74 C++ msci_uno.dll!`anonymous namespace'::cpp_call(bridges::cpp_uno::shared::UnoInterfaceProxy * pThis, bridges::cpp_uno::shared::VtableSlot aVtableSlot, _typelib_TypeDescriptionReference * pReturnTypeRef, long nParams, _typelib_MethodParameter * pParams, void * pUnoReturn, void * * pUnoArgs, _uno_Any * * ppUnoExc) Line 254 C++ msci_uno.dll!bridges::cpp_uno::shared::unoInterfaceProxyDispatch(_uno_Interface * pUnoI, const _typelib_TypeDescription * pMemberDescr, void * pReturn, void * * pArgs, _uno_Any * * ppException) Line 435 C++ invocadaptlo.dll!stoc_invadp::AdapterImpl::invoke(const _typelib_TypeDescription * pMemberType, void * pReturn, void * * pArgs, _uno_Any * * ppException) Line 474 C++ invocadaptlo.dll!adapter_dispatch(_uno_Interface * pUnoI, const _typelib_TypeDescription * pMemberType, void * pReturn, void * * pArgs, _uno_Any * * ppException) Line 622 C++ msci_uno.dll!`anonymous namespace'::cpp2uno_call(bridges::cpp_uno::shared::CppInterfaceProxy * pThis, const _typelib_TypeDescription * pMemberTypeDescr, _typelib_TypeDescriptionReference * pReturnTypeRef, long nParams, _typelib_MethodParameter * pParams, void * * pCallStack, __int64 * pRegisterReturn) Line 156 C++ msci_uno.dll!`anonymous namespace'::cpp_mediate(void * * pCallStack, long nFunctionIndex, long nVtableOffset, __int64 * pRegisterReturn) Line 341 C++ msci_uno.dll!`anonymous namespace'::cpp_vtable_call() Line 371 C++ tklo.dll!ActionListenerMultiplexer::actionPerformed(const com::sun::star::awt::ActionEvent & evt) Line 145 C++ tklo.dll!ActionListenerMultiplexer::actionPerformed(const com::sun::star::awt::ActionEvent & evt) Line 145 C++ tklo.dll!VCLXButton::ProcessWindowEvent::__l9::<lambda>() Line 589 C++ [External Code] tklo.dll!VCLXWindowImpl::OnProcessCallbacks(void * __formal) Line 303 C++ tklo.dll!VCLXWindowImpl::LinkStubOnProcessCallbacks(void * instance, void * data) Line 274 C++ vcllo.dll!Link<void *,void>::Call(void * data) Line 84 C++ vcllo.dll!ImplHandleUserEvent(ImplSVEvent * pSVEvent) Line 1960 C++ vcllo.dll!ImplWindowFrameProc(vcl::Window * _pWindow, SalEvent nEvent, const void * pEvent) Line 2507 C++ vcllo.dll!SalFrame::CallCallback(SalEvent nEvent, const void * pEvent) Line 276 C++ vcllo.dll!ImplHandleUserEvent(HWND__ * hWnd, long lParam) Line 4109 C++ vcllo.dll!SalFrameWndProc(HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam, int & rDef) Line 5771 C++ vcllo.dll!SalFrameWndProcW(HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam) Line 5905 C++ [External Code] vcllo.dll!ImplSalDispatchMessage(tagMSG * pMsg) Line 575 C++ vcllo.dll!ImplSalYield(bool bWait, bool bHandleAllCurrentEvents) Line 592 C++ vcllo.dll!WinSalInstance::DoYield(bool bWait, bool bHandleAllCurrentEvents, unsigned long nReleased) Line 658 C++ vcllo.dll!ImplYield(bool i_bWait, bool i_bAllEvents, const unsigned long nReleased) Line 506 C++ vcllo.dll!Application::Reschedule(bool i_bAllEvents) Line 532 C++ sblo.dll!SbiRuntime::Step() Line 740 C++ sblo.dll!SbModule::Run(SbMethod * pMeth) Line 1144 C++ sblo.dll!SbModule::Notify(SfxBroadcaster & rBC, const SfxHint & rHint) Line 810 C++ svllo.dll!SfxBroadcaster::Broadcast(const SfxHint & rHint) Line 51 C++ sblo.dll!SbMethod::Broadcast(unsigned long nHintId) Line 2135 C++ sblo.dll!SbxValue::SbxValue(const SbxValue & r) Line 63 C++ sblo.dll!SbxVariable::SbxVariable(const SbxVariable & r) Line 77 C++ sblo.dll!SbxMethod::SbxMethod(const SbxMethod & r) Line 872 C++ sblo.dll!SbiRuntime::FindElement(SbxObject * pObj, unsigned long nOp1, unsigned long nOp2, unsigned long nNotFound, bool bLocal, bool bStatic) Line 3523 C++ sblo.dll!SbiRuntime::StepELEM(unsigned long nOp1, unsigned long nOp2) Line 3999 C++ sblo.dll!SbiRuntime::Step() Line 772 C++ sblo.dll!SbModule::Run(SbMethod * pMeth) Line 1144 C++ sblo.dll!SbModule::Notify(SfxBroadcaster & rBC, const SfxHint & rHint) Line 810 C++ svllo.dll!SfxBroadcaster::Broadcast(const SfxHint & rHint) Line 51 C++ sblo.dll!SbMethod::Broadcast(unsigned long nHintId) Line 2135 C++ sblo.dll!SbxObject::Call(const rtl::OUString & rName, SbxArray * pParam) Line 299 C++ sblo.dll!StarBASIC::Call(const rtl::OUString & rName, SbxArray * pParam) Line 1358 C++ sblo.dll!BasicAllListener_Impl::firing_impl(const com::sun::star::script::AllEventObject & Event, com::sun::star::uno::Any * pRet) Line 3875 C++ sblo.dll!BasicAllListener_Impl::firing(const com::sun::star::script::AllEventObject & Event) Line 3898 C++ sblo.dll!InvocationToAllListenerMapper::invoke(const rtl::OUString & FunctionName, const com::sun::star::uno::Sequence<com::sun::star::uno::Any> & Params, com::sun::star::uno::Sequence<short> & OutParamIndex, com::sun::star::uno::Sequence<com::sun::star::uno::Any> & OutParam) Line 4032 C++ msci_uno.dll!`anonymous namespace'::callVirtualMethod(void * pAdjustedThisPtr, long nVtableIndex, void * pRegisterReturn, _typelib_TypeClass eReturnTypeClass, long * pStackLongs, long nStackLongs) Line 74 C++ msci_uno.dll!`anonymous namespace'::cpp_call(bridges::cpp_uno::shared::UnoInterfaceProxy * pThis, bridges::cpp_uno::shared::VtableSlot aVtableSlot, _typelib_TypeDescriptionReference * pReturnTypeRef, long nParams, _typelib_MethodParameter * pParams, void * pUnoReturn, void * * pUnoArgs, _uno_Any * * ppUnoExc) Line 254 C++ msci_uno.dll!bridges::cpp_uno::shared::unoInterfaceProxyDispatch(_uno_Interface * pUnoI, const _typelib_TypeDescription * pMemberDescr, void * pReturn, void * * pArgs, _uno_Any * * ppException) Line 435 C++ invocadaptlo.dll!stoc_invadp::AdapterImpl::invoke(const _typelib_TypeDescription * pMemberType, void * pReturn, void * * pArgs, _uno_Any * * ppException) Line 474 C++ invocadaptlo.dll!adapter_dispatch(_uno_Interface * pUnoI, const _typelib_TypeDescription * pMemberType, void * pReturn, void * * pArgs, _uno_Any * * ppException) Line 622 C++ msci_uno.dll!`anonymous namespace'::cpp2uno_call(bridges::cpp_uno::shared::CppInterfaceProxy * pThis, const _typelib_TypeDescription * pMemberTypeDescr, _typelib_TypeDescriptionReference * pReturnTypeRef, long nParams, _typelib_MethodParameter * pParams, void * * pCallStack, __int64 * pRegisterReturn) Line 156 C++ msci_uno.dll!`anonymous namespace'::cpp_mediate(void * * pCallStack, long nFunctionIndex, long nVtableOffset, __int64 * pRegisterReturn) Line 341 C++ msci_uno.dll!`anonymous namespace'::cpp_vtable_call() Line 371 C++ tklo.dll!PaintListenerMultiplexer::windowPaint(const com::sun::star::awt::PaintEvent & evt) Line 121 C++ tklo.dll!PaintListenerMultiplexer::windowPaint(const com::sun::star::awt::PaintEvent & evt) Line 121 C++ tklo.dll!VCLXWindow::ProcessWindowEvent(const VclWindowEvent & rVclWindowEvent) Line 461 C++ tklo.dll!VCLXWindow::WindowEventListener(VclWindowEvent & rEvent) Line 411 C++ tklo.dll!VCLXWindow::LinkStubWindowEventListener(void * instance, VclWindowEvent & data) Line 404 C++ vcllo.dll!Link<VclWindowEvent &,void>::Call(VclWindowEvent & data) Line 84 C++ vcllo.dll!vcl::Window::CallEventListeners(unsigned long nEvent, void * pData) Line 241 C++ vcllo.dll!vcl::Window::Paint(OutputDevice & __formal, const Rectangle & rRect) Line 1028 C++ vcllo.dll!PaintHelper::DoPaint(const vcl::Region * pRegion) Line 312 C++ vcllo.dll!vcl::Window::ImplCallPaint(const vcl::Region * pRegion, unsigned short nPaintFlags) Line 619 C++ vcllo.dll!vcl::Window::ImplCallOverlapPaint() Line 644 C++ vcllo.dll!vcl::Window::ImplHandlePaintHdl(Idle * __formal) Line 670 C++ vcllo.dll!vcl::Window::LinkStubImplHandlePaintHdl(void * instance, Idle * data) Line 646 C++ vcllo.dll!Link<Idle *,void>::Call(Idle * data) Line 84 C++ vcllo.dll!Idle::Invoke() Line 26 C++ vcllo.dll!ImplSchedulerData::Invoke() Line 48 C++ vcllo.dll!Scheduler::ProcessTaskScheduling(bool bTimerOnly) Line 183 C++ vcllo.dll!ImplYield(bool i_bWait, bool i_bAllEvents, const unsigned long nReleased) Line 518 C++ vcllo.dll!Application::Yield() Line 551 C++ vcllo.dll!Application::Execute() Line 468 C++ sofficeapp.dll!desktop::Desktop::DoExecute() Line 1361 C++ sofficeapp.dll!desktop::Desktop::Main() Line 1682 C++ vcllo.dll!ImplSVMain() Line 185 C++ vcllo.dll!SVMain() Line 224 C++ sofficeapp.dll!soffice_main() Line 166 C++ soffice.bin!sal_main() Line 48 C soffice.bin!main(int argc, char * * argv) Line 47 C soffice.bin!WinMain(void * _hinst, void * _dummy, char * _cmdline, int _nshow) Line 47 C [External Code]
Noel Grandin committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=19a4eaab9a55a2ecb33b727bad6307c5a2badc23 tdf#100337 Message boxes showup empty with white background It will be available in 5.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "libreoffice-5-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3be163c72925824eeadf5e75f6e0cf6229d8ceab&h=libreoffice-5-3 tdf#100337 Message boxes showup empty with white background It will be available in 5.3.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.