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

QMenu with auto-close stops QItem / QCheckbox working correctly #17735

Closed
dsl101 opened this issue Jan 7, 2025 · 7 comments
Closed

QMenu with auto-close stops QItem / QCheckbox working correctly #17735

dsl101 opened this issue Jan 7, 2025 · 7 comments
Labels

Comments

@dsl101
Copy link
Contributor

dsl101 commented Jan 7, 2025

What happened?

A QMenu with auto-close set does not functions correctly when the menu contains a QItem / QCheckbox combination as described here.

What did you expect to happen?

The checkbox model would be updated when clicking either the checkbox or item, and the menu would be closed.

Reproduction URL

https://codepen.io/dsl101/pen/bNbeeGm?editors=1010

How to reproduce?

  1. Open the settings menu without auto-close—clicking the item or checkbox updates the model value correctly
  2. Enable auto-close
  3. Clicking the QCheckbox now updates the model but does not close the menu
  4. Clicking the QItem closes the menu, but does not update the model

Flavour

Quasar CLI with Vite (@quasar/cli | @quasar/app-vite)

Areas

Components (quasar), Directives (quasar)

Platforms/Browsers

Firefox

Quasar info output

No response

Relevant log output

No response

Additional context

No response

@dsl101 dsl101 added kind/bug 🐞 Qv2 🔝 Quasar v2 issues labels Jan 7, 2025
@rstoenescu
Copy link
Member

Hi,

You need to manually stop the "click" event propagation on the items that you do not want to auto-close the menu.

<q-checkbox @click.stop ...

@dsl101
Copy link
Contributor Author

dsl101 commented Jan 14, 2025

I do want to auto-close the menu. The behaviour in the codepen is unchanged (I added your @click.stop). Still the checkbox doesn't close the menu, and the item doesn't toggle the setting...

@yusufkandemir yusufkandemir reopened this Jan 15, 2025
@rstoenescu
Copy link
Member

I'm now seeing that in your example, the label attached is not part of the QCheckbox. So you might be clicking the item label and seeing that the state does not change. So:

<q-item tag="label" @click.stop v-close-popup>

@dsl101
Copy link
Contributor Author

dsl101 commented Jan 15, 2025

I'm still not sure what's wrong with my explanation, unless the answer is just that 'auto-close doesn't work when using <q-item tag="label"'. I can use v-close-popup everywhere instead, but that is lots of repetition, as it's needed on the both the item and the checkbox, for every entry in the menu (see updated codepen).

I'm not sure what I did wrong so that "the label attached is not part of the QCheckbox". I used the code from here

If it's behaving as expected, it didn't seem to be documented anywhere...

@rstoenescu
Copy link
Member

Nothing wrong with your usage. I was just explaining why I initially mentioned to put the @click.stop on QCheckbox directly. I was under the impression that you are using it with label prop. But nothing wrong in using a QItem like you do.

I agree that this is a lot of repetition in adding @click.stop v-close-popup, but from a framework perspective we need to be careful not to add overhead for complex scenarios that are very rarely used. And we are also careful about the JS & CSS footprint (in KB). What would you like more about a framework: that it has significant overhead (that you cannot disable) no matter how you use it or having to write a bit more code at times? If your vue template has lots of repetition, you might want to do a v-for on your QItems. Main point is that yes, we could add your use-case too in the framework, but it would add unnecessary overhead for all QCheckboxes (and QMenus) & it would be very hard to customize the new behavior to fit all possible use-cases (which is totally a no-go from a framework perspective). I hope that you agree that runtime speed is essential for a framework.

@yusufkandemir
Copy link
Member

@rstoenescu I suggest we document this behavior/limitation instead, then. Would that be fine?

@dsl101
Copy link
Contributor Author

dsl101 commented Jan 15, 2025

@rstoenescu agree with all your points—I was just confused initially because the QMenu auto-close doesn't work in that QItem / QCheckbox combination lifted straight from the QItem documentation, and that seemed more like a bug than just "don't do that". I'm not sure that use-case is 'edge' (pretty common for us with settings menus), but no problem if there's a more performant solution.

If "use v-close-popup" when the menu contains QItem / QCheckbox combinations is the solution, that's fine, and documenting it in QMenu auto-close section maybe is the answer.

And, in trying to work through all that, this pattern seems to work even better, in that it doesn't require separate click handling. In effect, just use the QCheckbox to show the state:

<q-item v-for="(option, index) of setting.options" v-close-popup :key="index" clickable @click="option.value.value = !option.value.value">
  <q-item-section side>
    <q-checkbox :model-value="option.value.value" class="no-pointer-events"></q-checkbox>
  </q-item-section>
  <q-item-section>{{option.label}}</q-item-section>
</q-item>

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

No branches or pull requests

3 participants