You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you use flux:menu within flux:dropdown, it'll add overflow:hidden to the root HTML element.
This style attribute persists if you then wire:navigate away from the page, which is probably not desirable behavior.
You may say "Well obviously! It says to utilize flux:navmenu on the dropdown documentation page for this exactly reason". Which is true, however, is pretty easy to miss if you are copying your navbar directly from the header documentation page, which uses this exact type of menu (it doesn't include wire:navigate - but also doesn't include any warning about the overflow:hidden behavior)
Results in overflow:hidden persisting on root html element when navigating to Profile
How do you expect it to work?
I'd either expect overflow:hidden to be removed from the element when navigating to a different page, OR for this possibly unexpected behavior to be more prominent within the documentation so that I could appropriately choose flux:navmenu as the sub-item and not experience this behavior.
Please confirm (incomplete submissions will not be addressed)
I have provided easy and step-by-step instructions to reproduce the bug.
I have provided code samples as text and NOT images.
I understand my bug report will be closed if I haven't met the criteria above.
The text was updated successfully, but these errors were encountered:
I can confirm this is happening. At the moment the lockStroll styles are not being cleaned up on page navigate.
Below is a Volt component that demonstrates the issue. Make sure to have npm run dev running so the content has height.
Scroll down to the "Launch modal" button and launch the modal
Then click on the "Go to me" button in the modal, which should navigate you to the same page you are on
Then try and scroll again and it will be locked
@calebporzio I'm guessing we should set up a way to clean up flux stuff, so then a navigate listener can be set up to call that.
<?phpuseLivewire\Volt\Component;newclassextendsComponent{//};?>
<div>
<divclass="h-screen">Some long content to demonstrate the scroll not working</div>
<flux:modal.triggername="example">
<flux:button>Launch modal</flux:button>
</flux:modal.trigger>
<flux:modalname="example">
<flux:button:href="request()->url()"wire:navigate>
Go to me
</flux:button>
</flux:modal>
<divclass="h-screen">Some morelong content to demonstrate the scroll not working</div>
</div>
joshhanley
changed the title
Using Flux:menu within Flux:dropdown adds overflow:hidden to root html element - which persists if you wire:navigate to a new page
Scroll lock styles not being cleaned up on Navigate
Dec 19, 2024
Flux version
v1.0.29
Livewire version
3.5.17
What is the problem?
If you use
flux:menu
withinflux:dropdown
, it'll addoverflow:hidden
to the root HTML element.This style attribute persists if you then
wire:navigate
away from the page, which is probably not desirable behavior.You may say "Well obviously! It says to utilize
flux:navmenu
on the dropdown documentation page for this exactly reason". Which is true, however, is pretty easy to miss if you are copying your navbar directly from the header documentation page, which uses this exact type of menu (it doesn't includewire:navigate
- but also doesn't include any warning about theoverflow:hidden
behavior)Code snippets
Results in
overflow:hidden
persisting on root html element when navigating to ProfileHow do you expect it to work?
I'd either expect
overflow:hidden
to be removed from the element when navigating to a different page, OR for this possibly unexpected behavior to be more prominent within the documentation so that I could appropriately chooseflux:navmenu
as the sub-item and not experience this behavior.Please confirm (incomplete submissions will not be addressed)
The text was updated successfully, but these errors were encountered: