Dialog: background doesn't fit 100vh when safari's address bar is minimized on iOS 15.x

[Getz85]

What happened?

The address bar of safari on iOS 15.2.1 can be in a minimized state which affect the display of the shadow background when a Dialog is opened: the background doesn't take all the height of the viewport:

As we can see, the background doesn't take 100vh, but instead let a space of the height of the adresse bar maximized:

What did you expect to happen?

The background must fit to take all the height of the viewport.

Reproduction URL

https://quasar.dev/quasar-plugins/dialog#example--basic

How to reproduce?

1. On a mobile device with Safari and iOS > 15, go to the Dialog component documentation
2. Scroll the page to have the adresse bar minimized, and open a basic dialog from the examples.
3. The background should not fit the height of the viewport

Flavour

Quasar CLI (@quasar/cli | @quasar/app)

Areas

Components (quasar)

Platforms/Browsers

Safari, iOS

Quasar info output

Operating System - Linux(5.13.0-27-generic) - linux/x64
NodeJs - 16.3.0

Global packages
  NPM - 7.15.1
  yarn - 1.22.17
  @quasar/cli - 1.2.2
  @quasar/icongenie - Not installed
  cordova - Not installed

Important local packages
  quasar - 2.4.11 -- Build high-performance VueJS user interfaces (SPA, PWA, SSR, Mobile and Desktop) in record time
  @quasar/app - 3.2.9 -- Quasar Framework local CLI
  @quasar/extras - 1.12.4 -- Quasar Framework fonts, icons and animations
  eslint-plugin-quasar - Not installed
  vue - 3.2.27 -- The progressive JavaScript framework for building modern web UI.
  vue-router - 4.0.12
  vuex - 4.0.2 -- state management for Vue.js
  electron - Not installed
  electron-packager - Not installed
  electron-builder - Not installed
  @babel/core - 7.15.5 -- Babel compiler core.
  webpack - 5.62.1 -- Packs CommonJs/AMD modules for the browser. Allows to split your codebase into multiple bundles, which can be loaded on demand. Support loaders to preprocess files, i.e. json, jsx, es7, css, less, ... and your custom stuff.
  webpack-dev-server - 4.7.3 -- Serves a webpack app. Updates the browser on changes.
  workbox-webpack-plugin - Not installed
  register-service-worker - 1.7.2 -- Script for registering service worker, with hooks
  typescript - 4.5.4 -- TypeScript is a language for application scale JavaScript development
  @capacitor/core - Not installed
  @capacitor/cli - Not installed
  @capacitor/android - Not installed
  @capacitor/ios - Not installed

Quasar App Extensions
  *None installed*

Relevant log output

No response

Additional context

No response

[github-actions[bot]]

Hi @Getz85! 👋

It looks like you provided an invalid or unsupported reproduction URL. Do not use any service other than Codepen, jsFiddle, Codesandbox, and GitHub. Make sure the URL you provided is correct and reachable. You can test it by visiting it in a private tab, another device, etc. Please edit your original post above and provide a valid reproduction URL as explained.

Without a proper reproduction, your issue will have to get closed.

Thank you for your collaboration. 👏

[Getz85]

I can't reproduce the issue on a jsFiddle (https://jsfiddle.net/0sep4drt/show), probably because the page is included in a iframe. But this is can be easily reproduce on the documentation page.

[pdanpdan]

This is a bug in iOS, we hope it'll be fixed in the next few years :) https://stackoverflow.com/questions/68094609/ios-15-safari-floating-address-bar For the moment they are changing the behavior on most of the releases

[preetamslot]

https://github.com/quasarframework/quasar/issues/11402

[thexeos]

We have a chat with Quasar Layout and <q-footer> with message composer "working" in Safari and WKWebView.

It can never be perfect until they fix Safari, but this may (or may not) help:

diff --git a/node_modules/quasar/src/plugins/Screen.js b/node_modules/quasar/src/plugins/Screen.js
index 3eef4ea..3dbbcfb 100644
--- a/node_modules/quasar/src/plugins/Screen.js
+++ b/node_modules/quasar/src/plugins/Screen.js
@@ -62,8 +62,8 @@ export default defineReactivePlugin({
 
     this.__update = force => {
       const
-        w = window.innerWidth,
-        h = window.innerHeight
+        w = window.visualViewport !== void 0 ? window.visualViewport.width : window.innerWidth,
+        h = window.visualViewport !== void 0 ? window.visualViewport.height : window.innerHeight
 
       if (h !== this.height) {
         this.height = h

This was not the only change I've made, but without this, anything else I did had no effect.

[ibrainventures]

Btw: this Blue footer area on the image from the Issue-Opener is actually not really solvable

With / since iOS 15, Safari makes this "block element" if the body gets the position: fixed attribute (EDITED)

So actually the prevent background-scroll process for iOS in quasar is working.

(i am working with a not really nice patch, and instead of the position relative i am using the FL3NKEY/scroll-lock ).

But since iOS15 also this workaround got a unhappy effect. If Adressbar is bottom, the Adressbar slide in effect if scrolling inside the modal is happening, and if the Adressbar is top, the Safari Footer and Adressbar slides in ..)

[pdanpdan]

@ibrainventures In fact the other issue was correct :( For this one the solution is to use <meta name="viewport" content=".., viewport-fit=cover"> on iOS

[ibrainventures]

After reading a second time, i saw the difference ... :-/

[ibrainventures]

@pdanpdan but if the issue-opener means that blue block area, this is afik independent of the viewport-fit meta / inset safe-area. This happens on the actual Safari with QDialog / all body-position-fixed scrollpreventer. No adressbar -> iOS 15 - "position fixed" on body -> blocked area on the bottom.

[pdanpdan]

The blue zone problem can be observed in a simple page (scrollable) that has a fixed positioned element on it:

• child on address bar in iOS and make sure it is on bottom, and then select hide toolbar
• without viewport-fit=cover you can scroll up and show the blue zone
• with viewport-fit=cover you cannot scroll up and show the blue zone

When the address bar on bottom is hidden iOS behaves exactly the same as if it was not, so the page resizes exactly as if the bar would shrink/enlarge on scroll, except that it is transparent :)

It's not so simple, but it can be done almost perfectly: https://pdanpdan.github.io/quasar-docs/vue-components/dialog#basic

Problems:

• dialogs that show the virtual keyboard will allow the screen to show the blue zone (but it shrinks it)
• when web page is used as PWA on iOS, sometimes on first navigation on a page, if the page auto-scrolls to an anchor (and you stay on your left foot with a banana in your hand - and I cannot inspect PWA on iOS) there will be a jump in page when the dialog opens

[ibrainventures]

Tested and the scroll fullheight dialog without the safari-sliding-bottom-and-top-bars-effect looks very nice. :-)

But for this issue... and to understand it right, the given Link and the solution is not the classic quasar "body-position-fixed" scrollprevent usage? The body position looks on the first view "un-fixed" ..

On the first tryouts it sometimes scrolls to top, but this is controllable or a unsolvable side-effect?

[pdanpdan]

But for this issue... and to understand it right, the given Link and the solution is not the classic quasar "body-position-fixed" scrollprevent usage? The body position looks on the first view "un-fixed" ..

No, it's an experiment with using a static window and relative/overflow-hidden/size-and-position-specified body

On the first tryouts it sometimes scrolls to top, but this is controllable or a unsolvable side-effect?

I don't understand, but I think we should not pollute this issue - please open an issue or discussion in https://github.com/pdanpdan/quasar/issues

[ibrainventures]

wohoo :-) programmatic setting a overflow-y auto on the html and a height 110vh* on body also made the trick on my QDialogPlus (my good-old non body-position:fixed solution) component. So iOS15 safari stops his footer and adress bars slide-in/out and i have a 100 % viewport height full sized dialog with extensive-scrolling possibilites. (and btw. also the pull-to-refresh is away .. :-))) )

Thank you very much for this way / tipp. I will inspect and test a little more (also the scroll-to-top-effect) and open the next days a issue on your git.

*110vh = to fill all (also notched) areas and get a complete display filled content. (scrolling starts >110vh)

[raiika]

Just wanted to leave my trace here for future me and others, This problem was caused because of height 100vh and position: fixed, I succeed solving it with changing it to position: sticky, and the div won't become transparent when scrolling down.

[pdanpdan]

Interesting. Do you have a codepen with the solution?

[raiika]

not sure how to test in codepen, but here https://codepen.io/raiika/full/qBYzJgM

[BrodaNoel]

Use dvh instead of vh