Navigation "hamburger" broken on mobile layout

[wgordon17]

E.g., https://docs.openshift.com/container-platform/4.9/welcome/index.html

The hamburger menu appears to have it's z-index too low, and is therefore hidden under the header

Then scrolling down, it finally comes out of hiding

Before finally becoming usable

This was on a Chrome browser, on a desktop machine with the window-width fully minimized. Same thing happened on a Chrome browser on an iPhone.

There's also an issue I noticed using the "Google Search" app on my iPhone, where the hamburger menu isn't actually clickable, and doesn't scroll with page, just stays at the top. I can't replicate outside of the specific "Google Search" app.

[wgordon17]

cc @vikram-redhat

[jboxman-rh]

cc @aireilly

[aireilly]

Yes. This needs to change. Figured something like this would work: https://github.com/openshift/openshift-docs/issues/38512 thoughts?

[aireilly]

Fixed in https://github.com/openshift/openshift-docs/pull/38946

[kaovilai]

Another issue @aireilly is search doesn't work.

https://user-images.githubusercontent.com/11228024/153318565-ce7d05a2-8b27-439c-b6c6-50f1df8b806a.mp4

https://user-images.githubusercontent.com/11228024/153318567-6748f6f2-df05-408d-a991-8f57845246d6.mp4

[aireilly]

Thanks @kaovilai what browser and OS are you running? I can't replicate this on iOS 15.1 handset or in the Chrome Android emulator.

[kaovilai]

I was able to replicate on chrome as well but I was using edge.

Microsoft Edge  97.0.1072.78 (Official build) (64-bit)
Revision    41983664eb804a6406d8c9bc6f6adfacf07152da
Operating system    Android 12; Pixel 6 Build/SQ1D.220105.007
Google Play services    SDK=12451000; Installed=214815044; Access=3p
JavaScript  V8 9.7.106.19
User agent  Mozilla/5.0 (Linux; Android 12; Pixel 6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Mobile Safari/537.36 EdgA/97.0.1072.78
Command-line    --use-mobile-user-agent --top-controls-show-threshold=0.5 --top-controls-hide-threshold=0.5 --use-mobile-user-agent --enable-viewport --validate-input-event-stream --enable-longpress-drag-selection --touch-selection-strategy=direction --main-frame-resizes-are-orientation-changes --disable-composited-antialiasing --enable-dom-distiller --flag-switches-begin --flag-switches-end --top-controls-show-threshold=0.5 --top-controls-hide-threshold=0.5

[kaovilai]

@aireilly here I recorded a profile for you. You should be able to unzip and load it on your desktop computer Edge ( or maybe chrome too)'s inspect > Performance > Load Profile (arrow pointing up with a line on top).

It shows all the events happening.

Profile-20220210T111449.json.zip

[wgordon17]

Of course I don't have an Android device either 🙈 I used to actually be pretty handy with remotely debugging Chrome browser on Android devices with adb 😏

[kaovilai]

Ok I have pinpointed the issue to event Resize (which happens when keyboard pops up). You can replicate on desktop having window very thin, open the hamburger menu, then resize window. The hamburger menu went away, which closes the keyboard as well since text box is no longer in focus..

[wgordon17]

Interesting! Thanks @kaovilai, I'm seeing the same behavior with that resize now as well (I blame Android for causing a resize with the keyboard popup 😅 )...but lets see what we can figure out 😊

[kaovilai]

Fix here. https://github.com/openshift/openshift-docs/blob/b47f09e4ef238879eb32f8a17b2c67fbdda87146/_templates/_page_openshift.html.erb#L280

[kaovilai]

Well you shouldn't have to close the menu when resize happens.

[kaovilai]

Interesting! Thanks @kaovilai, I'm seeing the same behavior with that resize now as well (I blame Android for causing a resize with the keyboard popup 😅 )...but lets see what we can figure out 😊

Technically resize is the correct way to do things.. if you web app depends on correct size reporting.. and you don't resize when keyboard shows up... you're going to have a bad time forcing user to close keyboard unnecessarily.

[kaovilai]

Especially if content isn't expected to scroll but fit to screen such as games.

[wgordon17]

@kaovilai Yeah, I'm thinking the proper fix will be to use some kind of .sidebar-open class with display: block !important that way the resize doesn't override the state of the nav bar. I think we should be able to get this fixed pretty easily! Thank you for all your help on this!! Makes things so much easier 🙏

[aireilly]

+1 thanks @kaovilai :)

[kaovilai]

See you in the tower :)