Description: Editing a chart in the calc part of the iOS has the limitation, that not the whole sidebar is useable. A big part of the sidebar does not react on any actions. Please see the attached screenshot which shows which part reacts on any actions. Tested on 4.2 (35) Steps to Reproduce: 1. Create/open a calc file in the iOS app 2. Insert a chart 3. Tap on the chart and tap on “Edit Chart” in the sidebar 4. On the now show chart sidebar tap for example on “Y axis” Actual Results: Nothing happens. Expected Results: The “Y axis” should be removed. Reproducible: Always User Profile Reset: No Additional Info: It seems that all the elements below the switch “X axis” just don’t work.
Created attachment 157579 [details] The red area works, the part below does not work
Not to mention that the sidebar is too large to fit on screen. (But it can be scrolled; not sure if that is good UI, though.)
The problem can be reproduced, as far as I see, in a web-based Online "make run", too. (The exact border between which part of the sidebar reacts to input and which does not is a little different.)
If I collapse the "Elements" part of the sidebar, and the rest thus moves upward, then the elements in the rest start reacting to input. That makes me think that it might be quite easy to fix this, some calculation of what area in the sidebar should respond to input goes wrong.
Note to self: Debugging this, now looking at sfx2::sidebar::SidebarDockingWindow::EventNotify() in sfx2/source/sidebar/SidebarDockingWindow.cxx
One apparent red herring that I wasted time on was the "dockable" concept as in vcl/source/window/dockwin.cxx . I made sure that mbDockable is never set to true in the comphelper::LibreOfficeKit::isActive() case, but that did not help.
Note to self: More code pointers: chart2/source/controller/sidebar/ChartAreaPanel.cxx svx/source/sidebar/area/AreaPropertyPanelBase.cxx
Debugging, the difference if I compare a listbox in the Elements part (which works) to one in the Area part (which doesn't), is that in ImplHandleMouseEvent() in vcl/source/window/winproc.cxx, in the working case the call pChild->MouseButtonDown(aMEvt); goes to ImplBtn::MouseButtonDown() in vcl/source/control/imp_listbox.cxx, while in the non-working case, it goes to vcl::Window::MouseButtonDown() in vcl/source/window/mouse.cxx.
But if I collapse the Elements part, then clicking the listbox in the Area part *does* go to ImplBtn::MouseButtonDown(). Fun.
Fix in https://gerrit.libreoffice.org/c/core/+/89722 It was much more trivial than I had imagined.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/da57c32c5cb27eee38e32d10232b31d459c399df tdf#130348: Add special case for ChartDeck, too It will be available in 7.0.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/af8927b6aa210095bbf3b693ec56b4adb90e9d1d tdf#130348: Add special case for ChartDeck, too It will be available in 6.4.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
This issue is fixed and can be closed, tested in 4.2.3 (48). Thanks a lot to the Collabora team and especially to Tor for taking care of this!
Setting to VERIFIED based on comment 13