Pages menu is cut off in mobile landscape view

[Asadpalasara-multidots]

Description

Some of Menu items not visible.

Reproduction

1. Visit: https://wordpress.org/openverse/
2. Search anything using images search option in search box.
3. Change the screen viewport to the mobile devices.
4. Click on Button(Dots) https://prnt.sc/HutwN50nGtmO
5. Menu items showing till "API" then rest of items not visible.

Screenshots

https://prnt.sc/aUuprxKjkp2m

Environment

• Device: iPhone 12 Pro Landscape mode
• Browser: Chrome

[krysal]

Thanks for reporting this issue with all details @Asadpalasara-multidots. We'll work on general improvements for the whole header. CC @panchovm.

[fcoveram]

I can not reproduce the bug. Once reaching step 3 to see mobile views, the header changes and shows secondary menu's items inside the content switcher modal. See this gif.

[krysal]

@panchovm Try in an actual phone, not the browser emulator, that gives you the limited height that prevents seeing the whole dropdown menu, as @Asadpalasara-multidots shown in the screenshot.

[fcoveram]

Now I see it. We can tackle this by defining which breakpoint the header changes to its mobile version, and all menus are shown in full-size views. I will keep the needs design label to refer to it in a future design issue.

[sarayourfriend]

Changing the horizontal breakpoint probably doesn't fix the problem. If you have a wide but short device (like a horizontal smartphone, or a browser window aligned to the top half of your screen) this still happens.

We could make the inside of the menu scrollable?

[fcoveram]

Most devices' aspect ratios display the content in a proper layout, so the challenge seems to be picking a breakpoint where the navigation adapts correctly, as both navigational elements and search results, whether it is landscape or portrait. On desktop, or where you can control the browser size, there will always be cases of cutting the UI due to window size.

The scrollable menu sounds reasonable for this case, but I can not envision a smooth interaction in other situations unless you are thinking of special conditions for this behavior.

[zackkrida]

The core issue, to my mind, is having a sticky header combined with flyout/dropdown menus. This means that the height of the dropdowns can never exceed the user's screen height, which is a difficult thing to always guarantee. We'd have to find a way to use javascript to make sure the dropdowns are scrollable and never extend past the bottom edge of the viewport.

[sarayourfriend]

@zackkrida if we set max-height: calc(100vh - var(--button-height) - var(--header-top-padding)) or something like that, it'd solve that, right? Kind of ugly but 😬

[zackkrida]

That is true, and I guess we'd want to get those heights with refs. It does work pretty well, here's a hardcoded example:

[sarayourfriend]

That's kind of the thing with Tailwind, I'm not sure exactly how to do an escape hatch to be able to easily use variables for other things that need to reference shared sizes.

In this case I guess it's okay for it to use JS to calculate the variables because the menus are never open in the SSR render anyway.

[fcoveram]

As @zackkrida commented on PR #1257, this issue was not tackled in the code merged.

I wonder if we should set a header component shift based on the viewport's height, similar to the breakpoints logic. After seeing the image attached in the initial comment and this example, it might work using the header mobile version and show all actions in full-size menus.

[sarayourfriend]

We could use the max-height media query for that... Do you have any ideas for how tall the viewport would need to be for us to consider it a horizontally oriented mobile display?

[fcoveram]

I am trying to find stats about smartphone screen sizes and only found this site. It seems that 16:9 is the most widespread aspect ratio.

Since this might happen mostly on mobile devices, we can try calculating the viewport size in devices smaller than sm breakpoint and, if height is smaller than width, then shift to the mobile header. Likely I am missing some other inputs, but my point is detecting the device's landscape view as the criterion for the change.

[zackkrida]

The best fix here is probably to make sure if any of our popovers extend outside of the viewport, that we constrain their height and apply an internal scrollbar.

I'm going to mark this as 'help wanted', since it's likely someone in the community interested in frontend work could take this on.

[fcoveram]

Removing the needs design label as #1686 is developing a solution.