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

OverlayScrollbar is setting position: relative on its viewport element #489

Closed
vsarangan opened this issue Dec 27, 2022 · 8 comments
Closed

Comments

@vsarangan
Copy link

vsarangan commented Dec 27, 2022

Describe the bug
In Sidemenu, when the user hovers the main menu, respective child menu has to be displayed but that is showing if we apply the overlay scrollbar as directed by the document.

To Reproduce
In Sidemenu, when the user hovers the main menu, respective child menu has to be displayed but that is showing if we apply the overlay scrollbar as directed by the document.

  1. Hover the 'Menu 8'

Expected behavior
Should show the child menu of menu 8

Examples
https://stackblitz.com/edit/angular-xt3ejt

Environment

  • Used Operating System(s): macOS Monterey - 12.6
  • Used Browser(s) (with version): Safari 16.2

Additional context
Fix I tried
Style > Position: static in the overlay component and child os-viewport class it is working.

@KingSora
Copy link
Owner

KingSora commented Dec 27, 2022

@vsarangan Good day :)

Thanks for the report. I've published overlayscrollbars version 2.0.2 which removed position: relative from the .os-viewport element by default. You'll have to continue setting position: static on the root element though, since this is required on it or in your case on a parent element. I've updated your demo here: https://stackblitz.com/edit/angular-xzgdiz?file=src%2Fapp%2Fapp.component.ts

Note: This behavior is related to all browsers not just safari.

@KingSora KingSora changed the title OverlayScrollbar is not working as expected in safari browser version 16.2 OverlayScrollbar is setting position: relative on its viewport element Dec 27, 2022
@vsarangan
Copy link
Author

@KingSora Good day :)
Thanks for your timely response. the above solution that you have provided is still not working in safari 16.2.
I suspect this is because of the style overflow-y: scroll, if I remove the style then it is working fine in the safari browser. after removing the overflow-y mouse wheel is not working and hence user needs to manually scroll by using the vertical scrollbar

@KingSora
Copy link
Owner

@vsarangan The only difference in the example I posted is the position: relative change I explained. I didnt touch anything regarding overflow

@ddenev
Copy link

ddenev commented Dec 30, 2022

The removal of position: relative has broken my layout. You still have the top, right and left set on the .os-viewport element and removing the position: relative breaks those and now all my layout is displaced:
image

These are the styles for the .os-viewport element:
image

You can see (the i icons) that Chrome complains about having top, right and left on a position: static element.

Such breaking changes should be better though before implemented and if implemented, the breaking change should be well documented so that we do not blindly update to a broken version.

PS: @KingSora , quoting you to make sure you see this :)

@ddenev
Copy link

ddenev commented Dec 30, 2022

Could you please revert the previous behavior as:

  • the removal of position: relative is a breaking change
  • it actually does not solve the "niche" case described above (as @vsarangan mentions)

@KingSora
Copy link
Owner

KingSora commented Dec 30, 2022

@ddenev thanks for the report.. I wounder why this wasnt caught by any of the tests... I'll revert it as soon as I am home and improve the tests

also can you tell me what Operating System and browser youre using?

@ddenev
Copy link

ddenev commented Dec 30, 2022

thank you, @KingSora !

I'm on Windows 10 with Chrome (latest)

@KingSora
Copy link
Owner

KingSora commented Jan 1, 2023

@ddenev published v2.0.3 where this change is reverted... Sorry for the inconvenience!

@vsarangan Because of the breaking behavior I consider your case as a design limitation by the plugin. You can keep your workaround as it works in your case (no padding applied to root element and position: relative of the immediate parent element).

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

No branches or pull requests

3 participants