Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

QDrawer's behavior do not response correctly when zooming in and out #4328

Closed
tsewaiho opened this issue Jun 6, 2019 · 7 comments
Closed

Comments

@tsewaiho
Copy link

tsewaiho commented Jun 6, 2019

What steps did you take, to get the error?

Browser: Chrome

  1. Reset your zooming to 100%
  2. Go to https://quasar.dev/layout-builder
  3. Hide the right QDrawer
  4. Zoom in to 500%
  5. Show the Left QDrawer
  6. You will see that the QDrawer is in Mobile mode at this moment.
  7. Zoom out by CTRL + minus sign, step by step, all the way to 25%
  8. You will see that the QDrawer never go back to Desktop mode.

Another example

  1. Reset your zooming to 100%
  2. Go to https://quasar.dev/layout-builder
  3. right-click and Inspect the white background
  4. Delete the element which within QPage.
    THIS LINE
    <div color="secondary" class="q-stepper q-stepper--horizontal q-stepper--flat no-shadow q-stepper--bordered" style="max-width:600px;">
  5. Zoom in to 300%
  6. You will see that the Left and Right Drawer are still in Desktop mode, but it should go to mobile mode at this zooming level
  7. Zoom in to 400%
  8. Finally it changed to mobile mode.
  9. Zoom out back to 100%
  10. Show Left Drawer
  11. You will see that it still in mobile mode, but originally it is in desktop mode when zooming level is 100%

What did you get as the error?

This problem only appear on desktop. I also see this problem when using Firefox, but it result even less predictable, so I do not include in above steps.

My monitor's resolution is 1920x1080

@smolinari
Copy link
Collaborator

smolinari commented Jun 6, 2019

What reasons would there be for anyone to need to zoom in and out like that? I mean, if it's a vision impairment problem, they'd stick to a certain zoom level, right? Would the drawer behavior then be acceptable?

Scott

@tsewaiho
Copy link
Author

tsewaiho commented Jun 7, 2019

What reasons would there be for anyone to need to zoom in and out like that? I mean, if it's a vision impairment problem, they'd stick to a certain zoom level, right? Would the drawer behavior then be acceptable?

Scott

In the first example, if I zoom in to 200% on step 4, I can still reproduce this problem.

I have myopia and I wear glasses. But I am not seeing very clearly when reading Material Design based page, on Desktop only. So I always zoom around 100% - 300%
My monitor is 24 inch, 1920 x 1080. It is closest to the CSS px to absolute length ratio.
1cm == 37.8px
https://css-tricks.com/the-lengths-of-css/#article-header-id-3

In the second example, what I want to tell is, if your content is not long enough, it affect the Drawer. Isn't it very weird.
I discover this problem when I was learning this framework. I tried the Layout Components and its props thoroughly.

The document state that drawer behavior only depends on breakpoint and QLayout's width.
But turn off one side of drawer, or having not long enough content also affect drawer behavior.

@smolinari
Copy link
Collaborator

Thank you for the explanation. The devs will have a look I am sure.

Scott

@nothingismagick
Copy link
Contributor

nothingismagick commented Jun 7, 2019 via email

@tsewaiho
Copy link
Author

tsewaiho commented Jun 7, 2019

I totally understand your use case and I think that this is an issue related to the fact that many components use a range of differenr CSS units. There is an RFC linked below, and I would request you add your comments and research from this issue to that one and close this. #4274

Oh, I finished reading your post. But I think the root cause of my problem might not be related to hard coded pixel.

I have one more example, could you help me to verify?

Browser: Chrome
Tool: Vue DevTools and Chrome Dev tools

Steps:

  1. Render below template

  2. Reset the zoom level to 100% and visit the page.

  3. Open Vue DevTools, choose Components

  4. Inspect QLayout and check its width variable (in the data object), it should be equal to your monitor horizontal resolution.

  5. Switch to Chrome Dev tool's Elements tab, inspect the Qlayout element and check its computed css width, it should be equal to your monitor horizontal resolution too.
    THIS LINE: <div class="q-layout q-layout--standard">

  6. Zoom in your browser to 110%.

  7. Check again both values. The real css width is responsive, but the QLayout's width variable is not.

  8. Try different zooming level, the QLayout's width variable rarely change.

  9. At below template, comment out <p>few words</p>, uncomment <!-- <p style="height: 1000px">few words</p> -->

  10. Repeat step 1 to 8. Everything works as expected.

<template>
  <q-layout view="hHh lpR fFf">
    <q-header elevated class="bg-primary text-white">
      <q-toolbar>
        <q-btn dense flat round icon="menu" @click="left = !left" />

        <q-toolbar-title>
          <q-avatar>
            <img src="https://cdn.quasar.dev/logo/svg/quasar-logo.svg" />
          </q-avatar>
          Title
        </q-toolbar-title>

        <q-btn dense flat round icon="menu" @click="right = !right" />
      </q-toolbar>
    </q-header>

    <q-drawer v-model="left" side="left" bordered> </q-drawer>

    <q-drawer v-model="right" side="right" bordered> </q-drawer>

    <q-page-container>
      <q-page padding>
        <!-- <p style="height: 1000px">few words</p> -->
        <p>few words</p>
      </q-page>
    </q-page-container>
  </q-layout>
</template>
<script>
export default {
  data() {
    return {
      left: true,
      right: true,
    };
  }
};
</script>

Currently, I find that if I want the QDrawer to work as expected, I have to :

  1. use long enough content, but I cannot find a threshold
  2. use both side of drawer
  3. Do not hide the drawer in desktop mode.

@tsewaiho
Copy link
Author

tsewaiho commented Sep 1, 2019

I discover that all problems stated in this issue are fixed in v1.1.0.

@tsewaiho tsewaiho closed this as completed Sep 1, 2019
@rstoenescu
Copy link
Member

Thank you for checking out v1.1 and closing this issue!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants