Created attachment 107339 [details] color picker drop down location On Windows 7, the color picker appears in the center of the screen. Version: 4.4.0.0.alpha0+ Build ID: f33002aa5de7e88960e7c21286a661c89fd478c7 TinderBox: Win-x86@39, Branch:master, Time: 2014-10-04_03:31:18
The same will happen to any .ui-based popup, not only the new color picker. See, for example, the Undo/Redo drop-down control, which was converted to .ui by Caolán in commit 77ce41f2 — it also appears mid-screen.
I do not reproduce with my own build under Ubuntu 14.04 x86-64 (Version: 4.4.0.0.alpha0+ Build ID: ced24ffba2fa1754c466b7944b0ee06d21292706) MS-Windows only problem ? Best regards. JBF
This is vaguely reminiscent of bug 84591 "Styles dropdown disappears when clicked on submenu" in that: (a) A click on a split control tells LibreOffice to display something over the document window. (b) The problem is apparent on Windows but not on Linux. If you can stretch "the new item appears apart from the calling control" to include "the calling control disappears" as a special case", you have a third similarity. I hope this helps more than it confuses. If not, this comment is from my cat posting in my name. Terry.
Yes i can confirm that it also effects Undo and Redo drop downs and is limited to Windows.
Lets see if http://cgit.freedesktop.org/libreoffice/core/commit/?id=39428437d5ed9893007c915175f54c21dd03f95f makes a difference to this in any way
Yeah, that affects it alright
In todays build I have the color pickers at the expected places and undo/redo mid-screen. So tomorrows should have them all at the expected places http://cgit.freedesktop.org/libreoffice/core/commit/?id=7ce03365e8e655c4c9636d1acbc02c530114b2ce
Verified; it works. Thanks so much, Caolán!
@Caolán: Unfortunately now it's broken under kde4. Turns out that it's because the "visible" property you added to the color picker. Setting it to False or removing solves this. (And I wonder whether it is what fixed it for Windows, not the decoration bits?)
What goes wrong under KDE, mid-screen centering ?
(In reply to Caolán McNamara from comment #10) > What goes wrong under KDE, mid-screen centering ? Yes. And I also confirm that the undo popup is NOT fixed under Windows, tested with Build ID: 454f5c3018c6d61d5872f7c23c7590c2157444e4 from @42 tb.)
Yeah, toggling the visibility bit seems to be now that I can easily experiment with it is what got it fixed under windows. So did the same for the undo now as http://cgit.freedesktop.org/libreoffice/core/commit/?id=a2f80c9436faaace2cdabbc58be4e2e200f4ae3f Which I guess breaks KDE even further there. Does the generic vclplug have the same problems under KDE as the kde plug ?, i.e. export SAL_USE_VCLPLUGIN=gen
(In reply to Caolán McNamara from comment #12) > Does the generic vclplug have > the same problems under KDE as the kde plug ? Yes, it's affected from the visibility flag the same way. But it's even worse - sometimes clicking the dropdown arrow does nothing, and sometimes it even crashes with: X-Error: BadWindow (invalid Window parameter) Major opcode: 2 (X_ChangeWindowAttributes) Resource ID: 0x1a81891 Serial No: 17891 (17891) Setting visible to false solves this.
sigh, I haven't a clue why the visibility flag has the effect it does. I've had my struggles with popup windows before and different Window Managers.
@Caolán: Now I noticed that when the popup is opened, I always get the following warning: warn:legacy.tools:32103:1:vcl/source/window/window.cxx:855: Window::Window(): pParent == NULL Maybe this might give a clue on what's going on?
nah, that one is just for an unparented temp image in the color popup so shouldn't matter. And the undo one doesn't have that warning and reportedly has the same problem
I've found that in: void FloatingWindow::StartPopupMode( const Rectangle& rRect, sal_uLong nFlags ) { // avoid flickering if ( IsVisible() ) Show( false, SHOW_NOFOCUSCHANGE ); if I comment the Show call it shows in the right place, but unfortunately it creates a redrawing issue.
And now the most interesting part: Putting std::this_thread::sleep_for(std::chrono::milliseconds(100)); below that Show call, also makes the popups to show in the right place. Using lower values makes it to show in the wrong place sometimes. @Caolán: Maybe there is a race somewhere? Any idea?
*** Bug 89481 has been marked as a duplicate of this bug. ***