Fix regression around CSS stacking contexts and PIP widgets

[t3chguy]

Fixes element-hq/element-web#26805

Regressed by #12052

It added a rule #matrixchat { contain: strict; } which changed how the layout engine works.
It enabled CSS stacking contexts, which z-index cannot cross, its like a 2nd order z-index, the buttons were in the wrong stacking context for where they wanted to be drawn, so the PR moves them to the correct context (by moving it into the PersistentElement as that's a React Portal which renders outside of #matrixchat)

---

Here's what your changelog entry will look like:

🐛 Bug Fixes

• Fix regression around CSS stacking contexts and PIP widgets (#12094). Fixes PiP-PersistedElement rendered in front of Pip-buttons (Hiding call hangup and GoTo room buttons) element-hq/element-web#26805.

[toger5]

Thank you so much!
There are issues with the styling:

• The border radius of 8px is missing: this also missing in the css right now but will be added back in https://github.com/matrix-org/matrix-react-sdk/pull/12057/files
  This also is not working witht he new drawing anymore (I tried adding the radius in the devtools but the IFrame did not accept :border-radius: 8px;overflow: hidden; The border-radius work when adding a 0.989 opacity to the IFrame.
• The hangup and back button and footer/header gradients are too dark

[t3chguy]

The hangup and back button and footer/header gradients are too dark

I cannot reproduce this.

Before

After

Can reproduce the border radius issue though so will fix that.

After^2

[toger5]

This is what it looks for me:

On firefox. Looking through the css it seems like there is no explicit color css property on the hangup icon and the title text.

[t3chguy]

@toger5 cannot reproduce.

Before

After

Actually comparing the screenshots looks like app.element.io is darker?

[toger5]

This is what it looks for me: On firefox. Looking through the css it seems like there is no explicit color css property on the hangup icon and the title text.

I also tried on chrome where it looks the same as on FF.
Are you trying with you local build or with netlify? I am on trying with the netlify build. Maybe some dependencies are different.

[t3chguy]

I was trying on a local build but the above is on the Netlify.

[fkwp]

same issue for me on safari using the netlify build

[richvdh]

If this was a regression, could you link the PR that caused it, to help understand the fix? Or generally add some detail to the issue about how the problem came to be?

[toger5]

If this was a regression, could you link the PR that caused it, to help understand the fix? Or generally add some detail to the issue about how the problem came to be?

The problem occured because of using the strict contained mode as described in the issue: element-hq/element-web#26805 (comment).
The regression is: no interaction and wrong styling with pip elements.

@fkwp and me are having issues with the fix however that there are styling issues: (icon and text color is too dark). But @t3chguy cannot reproduce those.

[richvdh]

The problem occured because of using the strict contained mode as described in the issue: element-hq/element-web#26805 (comment).

I'm afraid I still don't really follow what changed.

@fkwp and me are having issues with the fix however that there are styling issues: (icon and text color is too dark). But @t3chguy cannot reproduce those.

Sounds like this is still in development, so moving this to draft for now.

[t3chguy]

Looks like its specific to light theme.

Moved the colour to fix.

[toger5]

Great! Thanks for fixing the light theme.

[richvdh]

I have no real idea what's going on here, I'm afraid. It looks vaguely plausible. Since I don't understand the nuclear reactor, I have some questions about the colour you have decided to paint the bikeshed.

[richvdh]

why are these changing?

[t3chguy]

So that they layer correctly relative to the PIP widget and tooltips and each other by having their own CSS stacking contexts

[richvdh]

wouldn't it make more sense for this to be passed as children, rather than a regular prop?

[t3chguy]

Children have different semantics of typically always being included, this only includes it when the iframe is shown, not when the loader or permissions prompt are shown

[richvdh]

Children have different semantics of typically always being included

I'm not entirely convinced about that. And if it's true, doesn't the same logic apply to PersistentApp?

But I don't feel strongly about it.

[richvdh]

why is this now needed (as well as the border-radius on .mx_WidgetPip_overlay ?

(I have no real idea what a &.mx_AppTileBody--call.mx_AppTileBody--mini is, I'm afraid)

[toger5]

Before the widget was always rendered the default app container with rounded borders.
This is a concious design decision to underline that it is not part of Eement web but potentially a thrid party app running as a widget. For calls we want to special case this and show the widget as if its part of Element Web.
So mx_AppTileBody--call has border-radius: 0px;.
For the PiP call view rounded corners are alwasy required. So we set it back to 8px.

Old:

Now:

Issue caused by new design

With:

    &.mx_AppTileBody--call.mx_AppTileBody--mini {
        border-radius: 8px;
    }

[richvdh]

Before the widget was always rendered the default app container with rounded borders.

I don't follow. There don't seem to be enough words in this sentence?

Eement

Element

alwasy

always

[richvdh]

seems plausible to me