Bug 131281 - Android Viewer: Doesn't display form controls
Summary: Android Viewer: Doesn't display form controls
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Android Viewer (show other bugs)
Version:
(earliest affected)
7.0.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Armin Le Grand
URL:
Whiteboard: target:7.2.0 target:7.0.5 target:7.1.0.2
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2020-03-11 12:03 UTC by Michael Weghorn
Modified: 2020-12-18 06:48 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
sample doc (9.57 KB, application/vnd.oasis.opendocument.text)
2020-03-11 12:23 UTC, Michael Weghorn
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Weghorn 2020-03-11 12:03:24 UTC
LibreOffice Android Viewer does not render/display form controls, like checkboxes and radiobuttons.

Steps to reproduce:

1) open the attached sample document "radiobutton_and_checkbox.odt" in Android Viewer

Observed behaviour

The document is displayed "empty", i.e. the radio button, as well as the checkbox and its label are not shown


The issue can also be observed with LibreOffice Online, or (probably best to debug) gtktiledviewer, like this:

  bin/run gtktiledviewer --lo-path=$PWD/instdir/program <PATH_TO_FILE>

Reproducible with current daily build, master~2020-03-10_23.37.28_LibreOfficeViewer-strippedUIEditing-debug.apk:

Version: 7.0.0.alpha0+
Build ID: 036da95dc5d0
Comment 1 Michael Weghorn 2020-03-11 12:23:11 UTC
Created attachment 158605 [details]
sample doc
Comment 2 Michael Weghorn 2020-03-11 14:21:50 UTC
While the fact that icons were not included for Android Viewer *might* have been part of the problem, doing so (s. https://gerrit.libreoffice.org/c/core/+/90330 ) by itself does not fix the issue.
Comment 3 Xisco Faulí 2020-03-11 15:20:05 UTC
Moving to NEW
Comment 4 Michael Weghorn 2020-03-12 12:15:32 UTC
Turns out this is a regression.

Bisected using 'gtktiledviewer' to the following commit:

    commit 424312aa99307da9f0ee60ea6e3213b2b3dc26b4
    Author: Armin Le Grand <armin.le.grand@me.com>
    Date:   Thu Feb 27 16:43:44 2020 +0100

        tdf#130768 Make tiled writer paint reuse decomposes
        
        See more info in comment 23 of task. Roughly it's
        about correcting a helper that led to destroying the
        View and thus the OC and thus the whole primitive
        buffering - what was expensive, for the case where
        decompositions were expensive
        
        Change-Id: Ic661ae810083a35812eaa923b439b3856b34b9ba
        Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89640
        Tested-by: Jenkins
        Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Comment 5 Michael Weghorn 2020-03-12 13:16:53 UTC
(In reply to Michael Weghorn from comment #2)
> While the fact that icons were not included for Android Viewer *might* have
> been part of the problem, doing so (s.
> https://gerrit.libreoffice.org/c/core/+/90330 ) by itself does not fix the
> issue.

And indeed, the icons are also needed. An Android build from the parent revision of commit 424312aa99307da9f0ee60ea6e3213b2b3dc26b4 (s. comment 4) shows the checkbox and radio button for the gtktiledviewer case, but not on Android Viewer.

Yet, after cherry-picking 367431b6987b75e7a201499bfbd25a41c92a4a59, 97e9a83888a377035f99fc6dd0566482469a3dfa and 7374fa59b929bea6792f80a6a819b2a06582722f on top of that, those are shown in Android Viewer as well, so what is needed is a fix for the regression mentioned in comment 4, and both, gtktiledviewer and Android Viewer should work.
Comment 6 PS Arniya 2020-07-06 10:09:36 UTC Comment hidden (spam)
Comment 7 Armin Le Grand 2020-12-09 15:07:26 UTC
Grepping, updating local stuff, looking into that change (for tiled rendering)...
Comment 8 Armin Le Grand 2020-12-09 15:13:29 UTC
Printing and export to PDF works...
Comment 9 Armin Le Grand 2020-12-09 16:47:21 UTC
Hard to debug :-/ Got no attach to running gtktiledviewer working yet...
Checked the RenderContextGuard using patchPaintWindow/unpatchPaintWindow to (it's a hack) draw to any OutDev without loosing the decmpositions, looks good. Checked what SdrPaintWindow constructor does with evtl. 3rd param (which is a Window) and if this may be needed. In principle hat patch/replacement is okay (despite being a 'solution' itself)...
Comment 10 Armin Le Grand 2020-12-09 17:16:23 UTC
Checked that ControlPrimitive2D creates a well-defined decomposition- what it does. Indeed it's handled in VclPixelProcessor2D::processBasePrimitive2D as case PRIMITIVE2D_ID_CONTROLPRIMITIVE2D in processControlPrimitive2D. When forcing decompose there (or by removing PRIMITIVE2D_ID_CONTROLPRIMITIVE2D) it works.
Thus - for some reason - it seems to be not painted...
Comment 11 Armin Le Grand 2020-12-09 19:44:02 UTC
Went through processControlPrimitive2D and checked - either forcing to decompose using

        process(rControlPrimitive);

which is in the catch-pass, or also forcing bControlIsVisibleAsChildWindow to false works and makes the controls appear.

That means: bControlIsVisibleAsChildWindow is true. Looking further shows that design-mode is ON in that mode. In design mode the controls are NOT painted by purpose since it means these are 'real' Windows and overlay the main window, so no need (and flicker) to paint them. 2nd prove is that I checked isDesignMode() at XControl which also says false (maybe added to calculate bControlIsVisibleAsChildWindow btw).

Then checked the office: Switching design mode off, saving testfile from this task, restart, reload -> design mode on again. Thus it seems this is the default now - if I remember correctly this was once saved/loaded as state info with the file...

But hat is the reason currently the controls are not painted. Tiled rendering would have to change the document default when loading to design mode on or draw the controls extra since is seems not to have the real Windows as controls.

Not sure why it worked before change 424312aa99307da9f0ee60ea6e3213b2b3dc26b4, but maybe the default for design mode changed in the meantime...?
Comment 12 Armin Le Grand 2020-12-09 19:46:00 UTC
OOps: design mode *off* again - of course. Is there a way to edit these comments?
Comment 13 Michael Weghorn 2020-12-10 06:48:34 UTC
(In reply to Armin Le Grand from comment #12)
> OOps: design mode *off* again - of course. Is there a way to edit these
> comments?

IIRC, buovjaga once mentioned that will be possible with a newer Bugzilla version.
Comment 14 Armin Le Grand 2020-12-10 14:49:04 UTC
Still fighting with debuggability - atach to running stuff withe endless loop and BP...
Comment 15 Aron Budea 2020-12-10 15:09:23 UTC
Thanks for looking at it, Armin! I haven't tried debugging with gtktiledviewer, but I can give advice on how to do it in LOOL. Start it using 'make run' (perhaps add '-j 8'), then you will see a process named something like 'kit_spare_001'. Attach the debugger to that, set your breakpoints, and open the file from your file system in the browser by modifying the sample URLs:
http(s)://localhost:9980/loleaflet/ccfc81dc0/loleaflet.html?file_path=file:///<path>/<file name>
Comment 16 Armin Le Grand 2020-12-10 16:16:48 UTC
Geting forward (including fprintf and gdb), checking various possibilities after checking the whole mechanism at doc load & layout mode of controls.
Comment 17 Armin Le Grand 2020-12-10 16:17:48 UTC
@Aron Budea: Thanks, will try immediately!
Comment 18 Aron Budea 2020-12-10 16:30:11 UTC
In the meantime I learned you can attach debugger to gtktiledviewer like this:
LO_TRACE="gdb --args" bin/run gtktiledviewer
Comment 19 Armin Le Grand 2020-12-11 09:07:59 UTC
So here we have it - after some debugging and checking for solutions (and debugging/fprintf mixes :-)). The reason is indeed that the FormControls have an exception state in DrawingLayer (which you have to know - not obvoious as so much stuff).
In the regular office the FormControls can be in layout mode (a) where they can be arranged/transformed (pos/size/...) as draw objects or not (b) where they are represented as 'real' VCL-System-Windows - as controls as existing on the UI at the target system. In mode (a) these need to be painted, in mode (b) not due to representing themselves as real child windows with own content and own paint - painting them in the containing (parent) win would be exactly cover these and leads to flicker (history stuff...).
The default is non-layout mode (thus b) at office start and state gets not (no longer...?) loaded with document. Thus an instance visualizing the doc (e.g. the office) needs to c reate these controls as system child windows in the UI type of the target system (client).
Thus the 'real' fix would be to teach the tiled renderer users (clients) to get the FormControl info and create system child windows in the UI of the client system as needed (would indeed be nice, every client would have it's interactive UI stuff in it's defined style of it's local system).
Since this is too much work, I will have to 'fallback' to just emulate case (a) when tiled rendering is used, e.g. detect in startup and set a flag to not create the system child windows as is done now - these are not 'visible' but unnecessarily created what might lead to problems, too...
Testing some possibilities that came to my mind (includinmg running unit tests to not break anything here...)
Comment 20 Armin Le Grand 2020-12-14 15:34:18 UTC
Doing some more checks, but getting to the point where I think from all solutions that came to my mind, the most simple is - probably - the best. Doing a full 'make check' cycle with that stuff...
Comment 21 Armin Le Grand 2020-12-15 00:02:32 UTC
Suggested solutionm on gerrit (see https://gerrit.libreoffice.org/c/core/+/107735)
Comment 22 Commit Notification 2020-12-16 12:50:10 UTC
Armin Le Grand (allotropia) committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/bcb8d2d3a08991b4e57189b81f8702aaa8af8a89

tdf#131281 Always draw FormControls when TiledRendering

It will be available in 7.2.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.
Comment 23 Commit Notification 2020-12-18 06:46:53 UTC
Armin Le Grand (allotropia) committed a patch related to this issue.
It has been pushed to "libreoffice-7-0":

https://git.libreoffice.org/core/commit/5592d5e97810e68bcc0a70b2892c4ad487a06f81

tdf#131281 Always draw FormControls when TiledRendering

It will be available in 7.0.5.

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.
Comment 24 Commit Notification 2020-12-18 06:47:06 UTC
Armin Le Grand (allotropia) committed a patch related to this issue.
It has been pushed to "libreoffice-7-1":

https://git.libreoffice.org/core/commit/f5331b17cb71096ee6f149db841b7802efa0c4c4

tdf#131281 Always draw FormControls when TiledRendering

It will be available in 7.1.0.2.

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.
Comment 25 Michael Weghorn 2020-12-18 06:48:56 UTC
Thanks, Armin!