Opened 4 years ago
Closed 5 months ago
#52354 closed defect (bug) (fixed)
Twenty Twenty-One: primary menu disappears at 481px
Reported by: | stephenbrook | Owned by: | karmatosed |
---|---|---|---|
Milestone: | 6.6 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Bundled Theme | Keywords: | has-patch commit |
Focuses: | accessibility, css | Cc: |
Description
Hi When I set screen width to 480px I see the mobile menu. At 482px, I see the desktop menu but at 481px there are no menus displayed.
I am using a chrome browser on windows 10. No active plugins and a fresh install of the theme.
Attachments (8)
Change History (33)
#2
@
4 years ago
I can’t replicate the same issue in my fresh installation. Can you please share your browser version so we can check the issue on that specific browser.
#3
@
4 years ago
Hi, the problem occurs in both of these browsers
Browsers
Google Chrome - Version 88.0.4324.104 (Official Build) (64-bit)
Microsoft Edge - Version 88.0.705.50 (Official build) (64-bit)
O/S - Microsoft Windows 10 Pro - Version 10.0.19041 Build 19041
#4
@
4 years ago
- Keywords needs-screenshots added
@stephenbrook Could you add screenshots?
I didn't see a problem at 481 pixels wide, either with the Responsive viewport mode or with the inspector panel open on the right side.
I tried in Chrome and Edge, with the same browser versions, though my Windows is different:
Windows 10 Home 20H2 (19042.746) with Windows Feature Experience Pack
#7
@
4 years ago
ok, here is a little twist. I tested this on another pc that is running Windows 10 Home Version 10.0.19042.746 and the problem does not exist. It is still a problem on my Windows 10 Pro pc.
#8
@
4 years ago
I am also unable to reproduce, now on Windows 10 PRO 10.0.19042 Build 19042
Chrome version Version 88.0.4324.150.
#9
@
17 months ago
I know this ticket is from a few years ago, but I've recently run into the same issue of having the menu disappear at a viewport width of 481 while using the Twenty-Twenty-One theme. I'm using a Windows 10 Pro and Chrome Version 113.0.5672.63 (Official Build) (64-bit). The screenshots that @stephenbrook provided in this ticket exactly mirror what I'm experiencing. I was advised on the WordPress forums to add my experience here. I'll include a link to that forum discussion for your reference: https://wordpress.org/support/topic/navigation-menu-disappears-2/#post-16744540. Does anyone know of a way to fix this? Thank you very much for any help you might be able to offer!
#10
@
6 months ago
- Keywords close reporter-feedback added
I realize we now have two people able to reproduce this but I am unable to. There are a few options here:
- For now, I am going to apply the 'close' keyword to reflect the majority of people are unable to reproduce.
- Whilst the close keyword is applied if steps can be given and it's still an issue please provide them. @kristenfisher427 specifically you might be able to confirm here if you are still experiencing this?
#11
@
6 months ago
- Keywords has-screenshots removed
Hi @karmatosed,
Thank you for your message and for looking into this! I installed the Twenty Twenty One theme and tested a viewport width of 481. Unfortunately, I still see the menu disappearing at that width. At this point in time, I've moved on to using other themes, so personally, it's not an issue for me. But I can confirm the bug is still occurring for some reason.
#12
@
6 months ago
- Keywords needs-testing added; close removed
Thank you @kristenfisher427 let's remove the close keyword then if you are still experiencing this and see if we can get this tested.
#14
@
6 months ago
The reason this bug is occurring is that the .primary-navigation > .primary-menu-container
(desktop menu) is visible when (min-width: 482px)
, while the .menu-button-container
(mobile menu) is visible when (max-width: 481px)
. That means that, if 481px < width < 482px (e.g., suppose the width is 481.5px), then neither menu will be visible.
I'm not sure how the original reporter was able to reproduce this at 481px; I suspect when the browser was displaying "481" the width was actually 481.5 (or possibly some other fractional value between 481 and 482) and rounded down or truncated for display purposes.
#15
@
6 months ago
I've added some attachments to illustrate the issue. Note that the only way I could reproduce it on my current machine was to set the zoom to 200%, but this may or may not be necessary depending on your system's pixel density, scaling factor, etc.
#16
@
6 months ago
- Focuses accessibility css added
- Keywords needs-patch added; needs-testing removed
- Milestone changed from Awaiting Review to 6.6
Thanks! I get that too, now, when zooming in (as low as 110%).
Bootstrap increases the precision of its max-width
media queries with pixel values such as 767.98px
.
To get similar values, each of the theme's Sass breakpoint calculations could subtract 0.02 instead of 1:
(max-width: #{$breakpoint_sm - 0.02})
#17
follow-up:
↓ 18
@
6 months ago
@siliconforks @sabernhardt
Hi all, were either of you able to reproduce this using Mac OS? Attempting with Chrome(v124) on Mac OS 13.5 and having trouble reproducing.
#18
in reply to:
↑ 17
@
6 months ago
Replying to jwgoedert:
Hi all, were either of you able to reproduce this using Mac OS? Attempting with Chrome(v124) on Mac OS 13.5 and having trouble reproducing.
I didn't test it on MacOS - the screenshots I posted were from Windows 10 with Chrome 123.
#19
@
6 months ago
My testing was also with Windows 10, but with Firefox (possibly v124 last week, 125.0.2 today). It happens when I adjust the browser window, not in Responsive Design Mode (which uses integers).
#20
@
5 months ago
- Keywords has-patch needs-testing added; needs-patch removed
The patch is Sass-only, so it needs to be compiled.
#21
@
5 months ago
I am not able to reproduce issue, but I also don't see any regressions with the patch applied. I tested in firefox, chrome, safari on macOS.
#22
@
5 months ago
- Keywords commit added; needs-testing removed
I was able to both reproduce the issue and apply the patch and observe the issue is fixed. I'm also not seeing any regression caused by this patch.
I think this is good to go; marking for commit.
I'm not super familiar with what our process is for making changes to the compiled CSS in core themes; would love for somebody else to commit this. @karmatosed?
#23
@
5 months ago
- Owner set to karmatosed
- Status changed from new to assigned
Thanks @joedolson I will take a look - there was fun earlier in the week around this so I can at least know how to fix when it goes wrong.
#24
@
5 months ago
I took a look at this and will do some more, currently if you compile the Sass using auto-script it does actually result in a range of additional things coming in, not just this patch. This isn't optimal, so I am going to explore how both to document better our scripting (then other committers can easier do this) and also see if I am even running the right script. I'll keep hold of this until that is confirmed.
If someone does commit this with that knowledge please share so we can document though, as it would be great to expose what script to run and also how to deal with the handful of themes that have compiling scripts, for all committers, within the documentation.
Hello @stephenbrook, welcome to WordPress Core Trac and thank you for opening this ticket!
I tried to reproduce the issue on Chrome/MacOS but it looks like it works fine on my side. I'll try to reproduce on Windows as soon as possible.