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
Created attachment 158605 [details] sample doc
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.
Moving to NEW
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>
(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.
Bluestacks is an Android emulator that provides an Android environment over Windows PCs / Laptops even on Apple Mac and Linux operating system machines. Cool and crazy apps are available for the Android platform and we all are fond of these android applications so why don’t we run them on our PC’s in desperate need. https://openapkfile.us/download-bluestacks/
Grepping, updating local stuff, looking into that change (for tiled rendering)...
Printing and export to PDF works...
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)...
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...
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...?
OOps: design mode *off* again - of course. Is there a way to edit these comments?
(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.
Still fighting with debuggability - atach to running stuff withe endless loop and BP...
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>
Geting forward (including fprintf and gdb), checking various possibilities after checking the whole mechanism at doc load & layout mode of controls.
@Aron Budea: Thanks, will try immediately!
In the meantime I learned you can attach debugger to gtktiledviewer like this: LO_TRACE="gdb --args" bin/run gtktiledviewer
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...)
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...
Suggested solutionm on gerrit (see https://gerrit.libreoffice.org/c/core/+/107735)
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.
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.
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.
Thanks, Armin!