quasarframework / quasar

Quasar Framework - Build high-performance VueJS user interfaces in record time
https://quasar.dev
MIT License
25.96k stars 3.52k forks source link

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

Open Getz85 opened 2 years ago

Getz85 commented 2 years ago

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:

ios-15-minimized

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

ios-15-ok

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] commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

thexeos commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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

ibrainventures commented 2 years ago

@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 commented 2 years ago

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

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:

ibrainventures commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

Interesting. Do you have a codepen with the solution?

raiika commented 2 years ago

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