Created attachment 124480 [details] animation of the problem When I'm editing a file and select diferent items from the document, for example, objects, formulas, images, paragraphs, etc. the toolbar move up and down appear and disappear depending on which object I´m. This is very annoying and makes me lose the cursor and changes the position of the elements of the toolbar. Gif http://imgur.com/53eL2wb Is there any chance to block the size of the toolbar? I enabled the "block toolbar position" but that didn`t work.
I can confirm with LO 5.2, win10. UX team - this is for sure known problem, but I can not find duplicate, thanks.
This is one of the most often reported annoyances. Switching the context leads to jumping UI. Devs POV is that you go into formula/chart/etc. edit mode, which is kind of a different application, and get the appropriate UI for that. UX tries to counteract this behavior by providing functions and properties from the sidebar. Meanwhile you could make the secondary toolbar floating, but I admit that this isn't a good workaround.
This is a windows-only regression and it doesnt happen in 5.0.5.2. Steps: 1) Open writer 2) Draw a shape 3) Click off the shape and the 'Formatting' toolbar appears without the 2nd toolbar row disappearing 4) Click the shape and the 2nd toolbar row will disappear before the 'Drawing Object Properties' toolbar appears. (In reply to Heiko Tietze from comment #2) > Devs POV is that you go into formula/chart/etc. edit mode, which is kind of > a different application, and get the appropriate UI for that. The problem shown in attachment 124480 [details] isnt about the toolbar issue when jumping into edit mode of OLE objects, but simply clicking on regular objects within a document, which changes the contextual formatting toolbar row. I had noticed this bug when you were screencasting on google hangouts from your windows VM, but assumed it was something specific to your setup. :D
This seems to have begun at the below commit. Adding Cc: to Michael Stahl; Could you possibly take a look at this one? Thanks c8b0384eac2821548e6cf6d632f738441ff74dba is the first bad commit commit c8b0384eac2821548e6cf6d632f738441ff74dba Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Wed Jul 22 19:39:47 2015 -0700 source 482c52e91fe41a52e68827e9bf64a9736427d517 author Michael Stahl <mstahl@redhat.com> 2015-06-26 11:01:51 (GMT) committer Michael Stahl <mstahl@redhat.com> 2015-06-26 21:14:46 (GMT) commit 482c52e91fe41a52e68827e9bf64a9736427d517 (patch) tree e71ffbc0d540833494e326f4bb03d10e21e97a14 parent c1e12b15e55a82f062960f40921e0c97afda2078 (diff) vcl: fix Win32 deadlocks from SolarMutexReleaser
the problem is apparently caused by TransferableHelper::CopyToSelection using SolarMutexReleaser. ... [ the message being dispatched there is SAL_MSG_TIMER_CALLBACK ... actually no the message isn't dispatched there usually only when the debugger messes up the timing ] ... real problem is an Idle being dispatched - SfxDispatcher::EventHdl_Impl - this pops a SwTextShell, SwNavigationShell off the stack and pushes SwNavigationShell and then it calls SfxDispatcher::Update_Impl which apparently updates the toolbar. ... this is happening inside SwView::SelectShell, here: eShellMode = SHELL_MODE_DRAW; m_pShell = new SwDrawShell( *this ); rDispatcher.Push( *m_pShell ); the SwDrawBaseShell constructor calls the CopyToSelection stuff... clearly it's not intended that the SfxDispatcher idle handler runs before the new shell is pushed onto the SfxDispatcher. the SfxDispatcher::xImp->aIdle is started from SfxDispatcher::Pop(). so either we shouldn't run the idle handler via SolarMutexReleaser, or something needs to prevent execution of the SfxDispatcher idle handler until the stack manipulation is finished.
Created attachment 124707 [details] stack trace of the premature idle invocation
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ea3ce0b3073c72f474365e438ddabd19de915b76 tdf#99383 vcl: don't dispatch events from SolarMutexReleaser It will be available in 5.2.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.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ea2c3f47682b79319d5ccaade4226f45aeec7369&h=libreoffice-5-1 tdf#99383 vcl: don't dispatch events from SolarMutexReleaser It will be available in 5.1.4. 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.
Confirmed fixed. Version: 5.2.0.0.alpha1+ Build ID: 389d8db4d90d427f886d06c3f7304ad973f0d39c CPU Threads: 2; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-05-19_00:15:59 Locale: en-US (en_US)
Thank you so much for your support!