fix: Fix content size

[danxuliu]

Fixes #660
Fixes #833
Fixes #981
Fixes #1020

The PDF viewer is meant to cover the full modal it is shown in, except for its header. And the modal is meant to use all the available height. The PDF viewer is inside a centered flexbox that is aligned with the bottom of the header, but that flexbox does not reach the bottom of the modal, as it is inside another element that "frames" it with a bottom margin equal to the header height. Therefore, the PDF viewer is expected to overflow its parent to cover that bottom margin, and as it is vertically centered in its parent it needs to use a top margin equal to the extra height at the bottom to "compensate" for that height and keep the alignment with the header.

In desktop computers this works fine, because the height of the modal matches the height of the viewport, so the height of the PDF viewer is the height of its parent plus the bottom margin. However, in mobile devices the viewport height might be larger than the actual viewport, for example when special UI elements like the navigation bar are being shown. When that happens, the height of the PDF viewer is larger than the height of its parent plus the bottom margin (as the height of the PDF viewer is based on the viewport size, and the height of its parent is based on the available height), so as the PDF viewer is vertically centered it ends overlapping the header at the top and being cut by the end of the page at the bottom.

Using dynamic viewport units (dvh) instead of viewport units (vh) for the height would solve the issue. However, that just happens to work because the modal uses all the available height. If the modal itself had a different height then the PDF viewer height would be wrong also when using dvh units. Therefore, the height of the PDF viewer should be based instead on the size of its parent. As mentioned the parent has a bottom margin that needs to be covered by the PDF viewer, so its height should be the height of its parent plus the height of the margin; while this also requires using an "external" size it is a "closer" one and should be conceptually easier to understand.

Besides all that, the top margin in the PDF viewer is used to compensate for the bottom margin in its parent, so it matches the header height only because the bottom margin in the parent is the header height. If a different height was used the top margin would be different than the header height, and it would be quite confusing. Therefore a better approach would be to explicitly align the PDF viewer with the top of its parent, which removes the need to use a top margin as it will be no longer vertically centered.

How to test

• Open the Files app
• Upload a PDF file
• Create a public share for the PDF file
• In a mobile device, open the link to the public share

Result with this pull request

The PDF is below the header, and scrolling to the bottom shows the end of the PDF file

Result with this pull request

The PDF overlaps the header, and scrolling to the bottom shows the end of the PDF file as well as the scroll bar cut

[danxuliu]

/compile amend /

[danxuliu]

/backport to stable31

[danxuliu]

/backport to stable30

[pierluigizagaria]

I think the modal issues are related on how the .modal-container behaves.

.viewer[data-v-af8ef248] .modal-wrapper .modal-container {
    top: var(--header-height);
    bottom: var(--header-height);
    height: auto;
    background-color: transparent;
    box-shadow: none;
}

This height: auto should still be height: calc(100% - var(--header-height)); so that the .modal-container sizing is properly calculated by removing the .modal-header height.

In this way the pdf viewer iframe does not have to use the position: absolute and can just use a height: 100% to fit the .model-container that is already sized to fill the entire viewport without overflows.

I've did some quick testing by using the Custom CSS module and fixed the header and bottom issues by overriding this two classes.

.modal-container {
  height: calc(100% - var(--header-height))!important;
}

.viewer__file {
  margin-top: unset!important;
  position: unset!important;
  height: 100%!important;
}

This is a screenshot of a pdf at the last page.

[danxuliu]

@pierluigizagaria Thanks for the analysis. But please note that by default the modal component in nextcloud-vue actually uses height: calc(100% - var(--header-height)); and therefore covers all the available space. However, the Viewer component explicitly overrides it to add a bottom margin and "frame" the contents, and the PDF viewer, which is shown inside the Viewer component, needs to work around that to cover all the available space again. That is why the bottom height is now added to the height of the PDF viewer in this pull request.

[pierluigizagaria]

I need to investigate where the height: auto comes from

[danxuliu]

I need to investigate where the height: auto comes from

It comes from the same Viewer component that sets the mentioned bottom margin (margin as in additional space, not as in CSS margin), as the height is implicitly defined by its top and bottom properties.

[szaimen]

Tested and seems to work. Thanks for fixing this! ☺️