Created attachment 71010 [details]
Base doc with two froms. One with grouping does not show group

I tested it with OOO330_m2, I can confirm this behavior.

One question remained how to create such grouping.
I can not reproduce it on empty form, please give a step by step description.

I notice that the grouping is shown OK when I open the document with 3.2.1
(OOO320m18, 9502).

Played around and found a scenario with 300m86:
1. Create form via wizard on a table and take a Grid on table.
2. Draw a Rectangle (or other Drawing object, tested not all objects).
3. Make a grouping on both
4. Save and close form
5. Reopen form
Now the drawing object is not shown.

Other observations:
A. When the grouping is on a grid of sub-form and a Drawing object, the grid is
not shown as well until one hovers over the grid with mouse.
B. Not showing control/objects also happens when group is made between other 
Form Control and Drawing object.

Hi - well, I can confirm the problem w/ the attached file (which actually causes
a different issue because of the mis-naming...lol) using DEV330m_2 / Ubuntu.

I confirm it, it seems to me as regression.
I created new form in OOo 3.2.1 as eremmel described, and it works in this version.

Opened form in OOO330_m3 and DEV300_86, the subform not shown until I went over
with mouse pointer.
The subform added object area color can be set, form not show it.

It is a regression.

Assign developer.

grabbing.
Can reproduce in OOO330.m3, will nominate as 3.3 blocker.

Created attachment 71090 [details]
simplified document to reproduce the bug case

in fact the problem here seems to be the grouping of form controls with other
objects - in such a case, both object types are invisible.

fs->aw: thanks for looking into this

AW: Does not happen in DEV300m84 with adding a shape and a form control and
grouping them. Does not happen in OOO330m7 when doing so. Trying the example
files...

AW: Does happen with DEV300m84 when constructing group, saving and reloading.
Preparing SW...

AW: Added FS to cc...

AW: In SW (0) is hell layer, (1) is heaven and (2) is control layer. When
constructing such a group (case A) initially the rect and the control are on
layer (2) (probably since some 'code' in grouping in SW does so ?!?). After
reload (case B) , rect is on (1) and control is on (2), as it should be.
The visibility test for VOCs (ViewObjectContactOfSdrObj::isPrimitiveVisible)
uses rObject.GetLayer() to check if the object is visible in this layer paint.

In case (A) the rectangle and the control get both painted in the FormLayer
repaint which is not correct, but works.

In case (B) the SdrObjGroup::GetLayer() implementation returns zero since the
childs have different LayerIDs. Thus, the group is handled in hell layer
repaint. Nothing is painted since the repaint also checks the
::isPrimitiveVisible calls for the single members.

Both is wrong, but it worked in previous versions, so something must have
changed which makes the already wrong behaviour in both cases now break in the
2nd case. Would it be better to find out why this ever worked or to risk to
correctly do it now...? Looking further...

AW: Found the code in SW which forces both objects on a single common layer, the
control layer, when SW is grouping objects. It's in SwDrawContact::SwDrawContact
and there is a comment which says (in german, translated here):

'controls have to be in the control layer always, also true for groups
containing controls'.

AW->OD: It looks as if this paradigm is not (or no more) applied after reload in
current versions. Look for the usages of CheckControlLayer in SW. Please have a
look if this is no more done at reload by purpose. If no, You may know best
where to reapply it. If Yes, we need to solve this differently.

AW->OD: The better solution would be not to 'bend' the LayerIDs for groups, but
to define that groups cannot be invisible by their LayerID (which may not be
uniquely defined with more than one object). Their content will be checked on
single SdrObject level for visibility anyways. This would be two steps:

- Remove all 'bendings' of SdrGroupObj LayerIDs in SW
- Implement a ViewObjectContactOfGroup::isPrimitiveVisible which is the same as
ViewObjectContactOfSdrObj::isPrimitiveVisible but without the first test for
LayerID.

I am just not sure if that bigger change is okay for OOO3.3; when the 'bending'
was just fallen out in the current version, it may be safer to re-install that one.

AW: Tried to add code to re-establish the mentioned paradigm (at
SwDrawContact::ConnectToLayout), but did not work in a first try.

Problem seems to be that the code for 'bending' in SwDrawContact::SwDrawContact
is too early at load time; it gets called when the import is creating the empty
group object, and does nothing there due to missing content. The content is
added later. Thus, i decided to take a look at SwDrawContact::_Changed which
handles actions like SDRUSERCALL_CHILD_INSERTED and SDRUSERCALL_CHILD_REMOVED
anyways. This seemed to be the right place to update the 'bending'. Tried and works.

I am not sure what side effects this may have, thus OD will have to check if
this is okay for OOo3.3. I will add the proposed fix as a patch.

Created attachment 71609 [details]
proposed patch which holds up the old paradigm after reload

Patch looks good.
Small adjustment: Assure that the group object keeps its visibility/invisibility
when changing its layer ID to the control layer.

Issue is planned to be fixed in cws sw33bf09

fixed in cws sw33bf09 - changed file:
/sw/source/core/draw/dcontact.cxx, change set 66542fad855f

od->es: Checked in internal installation set of cws sw33bf09 - please verify.

taking back again

fix failed :-(
reopening

Further corrections are needed.

Deeper investigation reveals that the defect has been introduced by the changes
for issue 161701

applied further corrections - changed files:
/sw/source/core/layout/fly.cxx,
/sw/source/core/frmedt/feshview.cxx,
change set 879c4cd0e18b

od->es: Checked in internal installation set of cws sw33bf09 - please verify.

notes for testing:
Please check further functions of drawing groups which contain control object.
E.g.:
- editing group
- inserting/removing control objects to/from existing drawing groups
- create/edit drawing groups which itself contain drawing groups
- repeat of tests at the created test documents after a save-close-load cycle

Verified in CWS sw33bf09

Is working in OOO330m9 (Build:9529)

then let's close it - thanks for the feedback