Bug 106762 - Color picker window in floating mode closes itself
Summary: Color picker window in floating mode closes itself
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
5.3.1.2 release
Hardware: All All
: medium normal
Assignee: Maxim Monastirsky
URL:
Whiteboard: target:6.0.0
Keywords: bibisected, bisected, regression
: 112412 114784 115991 (view as bug list)
Depends on:
Blocks: Color-Picker-Widget Regressions-serie-commits Floating-Menu
  Show dependency treegraph
 
Reported: 2017-03-25 02:21 UTC by Leandro Martín Drudi
Modified: 2018-02-25 10:52 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
Floating toolbar is not created (596.00 KB, image/png)
2017-03-25 02:21 UTC, Leandro Martín Drudi
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Leandro Martín Drudi 2017-03-25 02:21:56 UTC
Created attachment 132137 [details]
Floating toolbar is not created

When you drag and drop the menu to select the colors and make it make a floating toolbar, it is not created. It closes. It happens in all the programs of the suite.
Comment 1 tommy27 2017-03-25 08:41:29 UTC
tested under Win8.1 x64

not reproducible using LibO 5.2.5.1

reproducible using LibO 5.4.0.0.alpha0+

Build ID: 5bb5a9dacb84ec14f7148a5a5d9ba38b7e9f1039
CPU Threads: 4; OS Version: Windows 6.29; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-02-17_23:30:45
Locale: it-IT (it_IT); Calc: grou

status NEW
regression, needs bibisecting
added to Color Picker metabug

@Leandro
please tell your O/S
Comment 2 raal 2017-03-27 14:45:28 UTC
This seems to have begun at the below commit.
Adding Cc: to Caolán McNamara ; Could you possibly take a look at this one?
Thanks

bcdf4ea1ba4e6e9d1dbc89aec66fe57c89945634 is the first bad commit
commit bcdf4ea1ba4e6e9d1dbc89aec66fe57c89945634
Author: Jenkins Build User <tdf@pollux.tdf>
Date:   Mon Nov 7 22:23:35 2016 +0100

    source sha:64a708cba9b954afe3331f63c58218eb53b3d0ce

author	Caolán McNamara <caolanm@redhat.com>	2016-11-05 20:28:27 (GMT)
committer	Caolán McNamara <caolanm@redhat.com>	2016-11-07 21:04:50 (GMT)
commit	64a708cba9b954afe3331f63c58218eb53b3d0ce (patch)
tree	ddc1bea3b63f32a1c6d377c1d1dd7aee0803fb70
parent	f01c49c4a89ecad2376fd0023625186e5cac642e (diff)
Revert "Reverts a commit series that cripple windows ci."
with addition of...

- svxlo-SvxColorListBox
+ svxcorelo-SvxColorListBox

This reverts commit db380aab1063e8a5e40111c40ee9f7921aa82601.
Comment 3 Caolán McNamara 2017-03-31 11:32:39 UTC
As an aside the "undo" window is the same as this except it has always been like this and it has variously failed to work on various different platforms at different times cause of the complexity of making these sort of things floating.
Comment 4 Leandro Martín Drudi 2017-05-02 20:20:01 UTC
(In reply to Caolán McNamara from comment #3)
> As an aside the "undo" window is the same as this except it has always been
> like this and it has variously failed to work on various different platforms
> at different times cause of the complexity of making these sort of things
> floating.

Sorry... Is it a problem that the user can float the undo list? Because as a user I find it great to always have it in view to be able to control what is going to be undone. I do not think it's annoying but an option for users.
Sorry for the English. I use Google.
Comment 5 Caolán McNamara 2017-05-03 09:07:09 UTC
floating undo menu when undocked under gtk2 will auto close since forever, the whole floating thing is inconsistent across platforms
Comment 6 Heiko Tietze 2017-08-04 11:01:19 UTC
Usually expanded widgets are not floating. I would make them sticky to the parent and collapse when the focus is lost. However, the feature is quite comfortable, though we have alternative workflows like per sidebar or extra toolbars. The borders widget becomes an own floating control and remains visible until explicitly closed. So we should go one of the two ways and either have the floating option for all dropdowns or never.
Comment 7 Leandro Martín Drudi 2017-08-05 10:43:43 UTC
(In reply to Heiko Tietze from comment #6)
> Usually expanded widgets are not floating. I would make them sticky to the
> parent and collapse when the focus is lost. However, the feature is quite
> comfortable, though we have alternative workflows like per sidebar or extra
> toolbars. The borders widget becomes an own floating control and remains
> visible until explicitly closed. So we should go one of the two ways and
> either have the floating option for all dropdowns or never.
[ES]
La lista de colores siempre se convirtió en florante en versiones anteriores. A partir de que implementan una nueva versión dejó de funcionar.

[EN]
The color list always became floated in earlier versions. Since they implement a new version it stopped working.
Comment 8 Maxim Monastirsky 2017-09-17 06:30:39 UTC
*** Bug 112412 has been marked as a duplicate of this bug. ***
Comment 9 Maxim Monastirsky 2017-09-17 07:18:39 UTC
Making the tearoff mechanism itself work shouldn't be hard, as the only thing needed is to reparent the widget to a different FloatingWindow with the right WinBits, so that we can avoid setting problematic WinBits on the initial popup window (like WB_OWNERDRAWDECORATION which creates focus and placement issues under gtk3/wayland). All existing popups which allow tearoff were already converted to work that way via svt::PopupWindowController + DockingManager (e.g. Bug 109309).

The problem here is that the color widget is .ui based, and sadly it results with some layout problems with the current DockingWindow + DockingManager code. So far all my attempts to make it have the right size and not flicker or change its size randomly were unsuccessful. But I keep trying, so I'm assigning that bug to me for the time being.
Comment 10 Commit Notification 2017-09-24 12:55:04 UTC
Maxim Monastirsky committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=ad769c30d2a709786a769f75fa5e04b33edf0809

Adjust DockingWindow layout calculation, tdf#106762 prep

It will be available in 6.0.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.
Comment 11 Commit Notification 2017-09-24 12:55:12 UTC
Maxim Monastirsky committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=8f1e01fc89ca5d5f03d172f038e2310ba2ac5580

Support non-ToolBox popup case in DockingManager, tdf#106762 prep

It will be available in 6.0.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.
Comment 12 Commit Notification 2017-09-24 12:55:19 UTC
Maxim Monastirsky committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=8bd418a6b8253a9d725981743a0375e2c8bb911e

rptui::OToolboxController becomes unused, tdf#106762 related

It will be available in 6.0.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.
Comment 13 Commit Notification 2017-09-24 12:55:29 UTC
Maxim Monastirsky committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=e867b197540cfc8b75bb1108c8bcd7a0ff65d347

tdf#106762 Base SvxColorToolBoxControl on svt::PopupWindowController

It will be available in 6.0.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.
Comment 14 Commit Notification 2017-09-24 12:55:40 UTC
Maxim Monastirsky committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=bf9360e6f5e38c9de3b38d9748a84d4d1c5067f9

tdf#106762 Keep the previous m_xColorWindow lifecycle

It will be available in 6.0.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.
Comment 15 Commit Notification 2017-09-24 12:55:48 UTC
Maxim Monastirsky committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=10e5729fb07d6b4c66182596bd86734d0ab386b9

tdf#106762 Avoid warning when opening and closing the color picker

It will be available in 6.0.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.
Comment 16 Jean-Baptiste Faure 2017-09-24 15:33:41 UTC
Hi Maxim,

Thank you very for this fix. I tested it on my own master build and it works as expected.

Did you see that LO seems to create two different color picker objects depending if you use the formatting toolbar or the sidebar. At least it is what it is suggested to me when I see that each color picker remember its own last used color. I don't know if that should be called a bug or a feature because some user may be interested to have 2 memorized colors when he changes paragraph background color or font color.

Anyway setting as verified fixed.
Best regards. JBF
Comment 17 V Stuart Foote 2017-12-31 18:03:24 UTC
*** Bug 114784 has been marked as a duplicate of this bug. ***
Comment 18 Maxim Monastirsky 2018-02-25 10:52:51 UTC
*** Bug 115991 has been marked as a duplicate of this bug. ***