Fix hidden invite link area except transfer dialog and devtools button area

[luixxiul]

Fixes element-hq/element-web#20911
Closes #7966

• Disable overflow: hidden on the invite dialog with footer, except the transfer dialog for now
• Remove the height setting with a magic number
• Style .mx_CopyableText area with white-space: nowrap to make text ellipsis work
• Reset the default button margin to put the button at the bottom of the dialog

As long as the height is specified with a magic number, the area is going to be hidden anyway.

The overflow style was introduced with here (based on here) related to dialpad improvements, so this PR avoids applying the style to the transfer dialog with :not(.mx_InviteDialog_transfer). This exception should be removed after it is confirmed that this change can also be applied to that dialog without a visual regression.

Signed-off-by: Suguru Hirahara luixxiul@users.noreply.github.com

type: defect

---

Here's what your changelog entry will look like:

🐛 Bug Fixes

• Fix hidden invite link area except transfer dialog and devtools button area (#8165). Fixes Some dialogs are cut off on the bottom edge element-hq/element-web#20911. Contributed by @luixxiul.

Preview: https://pr8165--matrix-react-sdk.netlify.app
⚠️ Do you trust the author of this PR? Maybe this build will steal your keys or give you malware. Exercise caution. Use test accounts.

[codecov]

Codecov Report

Merging #8165 (09b8a6f) into develop (cdb0c2c) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           develop    #8165   +/-   ##
========================================
  Coverage    29.25%   29.25%           
========================================
  Files          863      863           
  Lines        49876    49876           
  Branches     12696    12696           
========================================
  Hits         14592    14592           
  Misses       35284    35284           

[turt2live]

I don't believe this issue is unique to the invite dialog. Having looked at other dialogs, like the Share dialog, devtools, etc, they are all cut off on the bottom by 1 pixel border's worth.

This implies that something else is causing the issue.

[luixxiul]

The issue on Devtools is actually caused by another height setting on this line of _DevtoolsDialog.scss. I guess any dialogs styled with height: calc(100% - x) should have the same issue, potentially or not.

[luixxiul]

I've fixed both issues. Please check again, thanks.

It seems to me the fundamental issue here would be that there is not an unified, common way of placing buttons on the bottom of a dialog; it looks like each dialog handles them in its unique way, which should be the root cause of this kind of inconsistencies. However, since normalization is out of scope of this PR, I would leave the task for another one.

[turt2live]

I'm still generally concerned that the change is wider spread than the two dialogs. I'm very mindful that we have half a dozen ways to construct a dialog, but finding the commit/change which caused the regression in the first place would be ideal to help identify all of the affected dialogs.

I don't think we need to introduce flexboxes in the dialogs to fix this.

[luixxiul]

finding the commit/change which caused the regression in the first place would be ideal to help identify all of the affected dialogs.

Should this PR be closed in favor of another PR which is supposed to normalize the dialogs? I am asking this because this PR first intended to cover the invite dialog (and devtools dialog) only

[turt2live]

Preferably we expand the scope to fix the root issue rather than a specific dialog. If that means closure, so be it.

[luixxiul]

I am not really sure whether there would be one ultimate root cause, as each area has been created differently at different timing.

For those who are willing to work on this issue: you should check each dialog with .mx_Dialog to detect which commits introduced what is styled with fixed height (such as the header), and globally replace the style with something else which does not hide the bottom area.

[luixxiul]

I don't think we need to introduce flexboxes in the dialogs to fix this.

I researched a little bit, and I guess that by introducing flexbox it should be able to achieve something similar to https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Flexible_Box_Layout/Typical_Use_Cases_of_Flexbox#card_layout_pushing_footer_down

.card {
    display: flex;
    flex-direction: column;
}

.card .content {
    flex: 1 1 auto;
}

If it is possible to consider the dialog as one card layout, why not applying the same way?

[luixxiul]

To design team: I would like to know if it is reasonable to apply the card layout for the dialogs to push down the button area to the bottom. Thank you in advance.