Bug 84676 - .ui-based drop-down controls appear floating mid-screen, as opposed to attached to their buttons
Summary: .ui-based drop-down controls appear floating mid-screen, as opposed to attach...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
4.4.0.0.alpha0+ Master
Hardware: Other Windows (All)
: high normal
Assignee: Caolán McNamara
URL:
Whiteboard: BSA target:4.4.0
Keywords:
: 89481 (view as bug list)
Depends on:
Blocks: Color-Picker-Widget
  Show dependency treegraph
 
Reported: 2014-10-04 23:57 UTC by Yousuf Philips (jay) (retired)
Modified: 2015-12-03 08:54 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
color picker drop down location (96.72 KB, image/png)
2014-10-04 23:57 UTC, Yousuf Philips (jay) (retired)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) (retired) 2014-10-04 23:57:42 UTC
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
Comment 1 Adolfo Jayme Barrientos 2014-10-05 07:04:50 UTC
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.
Comment 2 Jean-Baptiste Faure 2014-10-05 07:33:35 UTC
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
Comment 3 Terrence Enger 2014-10-05 21:58:41 UTC
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.
Comment 4 Yousuf Philips (jay) (retired) 2014-10-06 01:48:17 UTC
Yes i can confirm that it also effects Undo and Redo drop downs and is limited to Windows.
Comment 5 Caolán McNamara 2014-10-16 14:32:48 UTC
Lets see if http://cgit.freedesktop.org/libreoffice/core/commit/?id=39428437d5ed9893007c915175f54c21dd03f95f makes a difference to this in any way
Comment 6 Caolán McNamara 2014-10-20 14:54:22 UTC
Yeah, that affects it alright
Comment 7 Caolán McNamara 2014-10-20 14:55:58 UTC
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
Comment 8 Adolfo Jayme Barrientos 2014-10-20 15:13:29 UTC
Verified; it works. Thanks so much, Caolán!
Comment 9 Maxim Monastirsky 2014-10-20 17:43:18 UTC
@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?)
Comment 10 Caolán McNamara 2014-10-20 19:21:55 UTC
What goes wrong under KDE, mid-screen centering ?
Comment 11 Maxim Monastirsky 2014-10-20 19:32:04 UTC
(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.)
Comment 12 Caolán McNamara 2014-10-21 10:41:34 UTC
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
Comment 13 Maxim Monastirsky 2014-10-21 15:22:18 UTC
(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.
Comment 14 Caolán McNamara 2014-10-21 16:15:12 UTC
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.
Comment 15 Maxim Monastirsky 2014-10-26 09:18:53 UTC
@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?
Comment 16 Caolán McNamara 2014-10-30 12:38:33 UTC
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
Comment 17 Maxim Monastirsky 2014-10-30 17:11:00 UTC
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.
Comment 18 Maxim Monastirsky 2014-11-01 21:38:13 UTC
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?
Comment 19 Adolfo Jayme Barrientos 2015-07-05 05:51:56 UTC
*** Bug 89481 has been marked as a duplicate of this bug. ***