Description: after a longer time of editing a form, the controls disappear and the form is damaged. I will provide the database with the damaged form. meanwhile it happened four times and the result of work is lost. It is impossible to reproduce. I only can say, that it happens after many (100 or more) changes of attributes in Controls of a form. Steps to Reproduce: 1.impossible to reproduce step by step. do many changes during a longer time. 2. 3. Actual Results: *) in the forms navigator all controls and subforms are present. *) it is also possible to select the hidden controls - example grid coordinates (x / y) = (10.0 / 0.9) *) selecting the visible controls are making the respective control in the forms navigator selected too *) selecting the invisible object (10.0 / 0,9) does not select an object in the forms navigator *) the invisible objects do no longer have attributes for coordinates and size shown in control properties window - the visible do have them *) selecting "position and size" from the contex menu of the invisible objects are showing the correct coordinates. *) conclusion: it looks like the hidden objects did loose their identity as a control in a form and behave the same way, for example a rectangle would do, If I add it by using the normal drawing tools. Expected Results: Forms not going to be damaged Reproducible: Sometimes User Profile Reset: Yes OpenGL enabled: Yes Additional Info: Version: 7.0.3.1 Build ID: d7547858d014d4cf69878db179d326fc3483e082 CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3 Locale: de-AT (en_US.UTF-8); UI: en-US Calc: threaded OpenGL: renderer: SVGA3D; build v: 2.1 Mesa 20.0.8 direct render: Yes
Created attachment 167316 [details] Database with damaged form and reduced queries and tables
I will provide the form at my starting point in the next attachment. I created this form by using the forms wizard. this time I started LO from console. I changed for control "fmtVertragsID" the attribute "vertical alingment" to "middle" and got in the terminal window all these lined fired only from this one attribute change. (soffice:18161): Gtk-CRITICAL **: 21:09:11.945: gtk_notebook_get_tab_label: assertion 'list != NULL' failed (soffice:18161): Gtk-CRITICAL **: 21:09:11.946: gtk_notebook_get_tab_label: assertion 'list != NULL' failed (soffice:18161): Gtk-CRITICAL **: 21:09:11.947: gtk_notebook_get_tab_label: assertion 'list != NULL' failed (soffice:18161): Gtk-CRITICAL **: 21:09:11.955: gtk_notebook_get_tab_label: assertion 'list != NULL' failed (soffice:18161): Gtk-CRITICAL **: 21:09:11.956: gtk_notebook_get_tab_label: assertion 'list != NULL' failed (soffice:18161): Gtk-CRITICAL **: 21:09:11.957: gtk_notebook_get_tab_label: assertion 'list != NULL' failed
Created attachment 167319 [details] including the form, where i started from
I continued testing now with the alpha release Version: 7.1.0.0.alpha1+ Build ID: 03a9a80125cf887d26348486b71d78d80c99344d CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3 Locale: de-AT (en_US.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-11-07_18:04:03 Calc: threaded OpenGL: renderer: SVGA3D; build v: 2.1 Mesa 20.0.8 direct render: Yes ~~~~~~~~~~~~~~~~ I selected "fmtVertragsID" and "lblVertragsID" (at the left corner above) and aligned then in "horizontal middle, using the icon in the toolbar. This time I got at the console: (soffice:3487): GLib-GObject-CRITICAL **: 21:52:57.754: g_object_get_qdata: assertion 'G_IS_OBJECT (object)' failed ~~~~~~~~~~~~~ the activities, done at LO 7.0.3, I repeated too: they did not produce that "critical" messages on LO 7.1. alpha
I have got the same error with LO 7.0.3.1 Changed the properties of some fields, saved the form - and most of the fields were lost. Then I tried to reproduce the behavior, but I couldn't. Never had such a buggy behavior before with forms. Now I'm copying forms and saving forms every time I have changed something with a new name. Seems forms get as instable as reports are ... My system: OpenSUSE 15.1 with LO 7.0.3.1 and VCL: gtk3
Created attachment 167344 [details] I would like to point more precise at what I described in my comment4
When editing the form for testing in BUG138409.odb it happened again in the daily build too! Version: 7.1.0.0.alpha1+ Build ID: 4486ab59348ddbfa4b050195477c2842c0a7de0a CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3 Locale: de-AT (en_US.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-11-21_13:22:04 Calc: threaded
On Fedora 33, I'm using: Version: 7.0.5.2 Build ID: 00(Build:2) CPU threads: 8; OS: Linux 5.11; UI render: default; VCL: gtk3 Locale: en-US (en_US.utf8); UI: en-US Calc: threaded In LibreOffice Draw I got this error on the console when editing a drawing: (soffice:125532): GLib-GObject-CRITICAL **: 10:31:26.773: g_object_get_qdata: assertion 'G_IS_OBJECT (object)' failed
I rename this bug to error, since there are different ways to reproduce it. In my case, LO 7.2+ in GTK3: 1. open DOCX attachment 172813 [details] from bug 142794 2. double click on chart to edit 3. see console errors: Gtk-CRITICAL **: 09:06:11.989: gtk_tree_view_scroll_to_cell: assertion 'tree_view->priv->tree != NULL' failed (soffice:32374): Gtk-CRITICAL **: 09:06:15.555: gtk_notebook_get_tab_label: assertion 'list != NULL' failed Note: fixing this one doesn't have to fix reported one, but since that one doesn't have steps, we will know later.
The gtk_notebook_get_tab_label assert is (IIRC) this upstream issue: https://gitlab.gnome.org/GNOME/gtk/-/issues/2817 and I don't think it causes any practical problems The gtk_tree_view_scroll_to_cell warning is possibly part of bug 148197 and that one could cause trouble IIRC, I can't reproduce it in trunk at least so that aspect is likely fixed (?) There are a lot of different things in this particular bug and it seems to have drifted from the original bug so its unclear what would constitute a resolved state here.
Hello Caolan, I agree: there are a lot of different things mixed together in this bug. Comment 8 describes a bug in DRAW, comment 9 relates to DOCx. My issue was related to BASE. When I raised this incident, I HAD a problem! Damaged Forms are indeed a problem. With the latest release (see below) I can no longer reproduce the bug. Version: 7.4.2.3 / LibreOffice Community Build ID: 382eef1f22670f7f4118c8c2dd222ec7ad009daf CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: de-AT (en_US.UTF-8); UI: en-US Calc: threaded
seeing as Richard was the original reporter and "can no longer reproduce the bug" on the original substantive issue lets call this fixed and if there are remaining problems feel free to submit extra bugs for them