Divi collapse mobile menu: find the width

Divi's builder lets you set a menu once for desktop and then adjust it for tablet and phone. You work in a preview you resize yourself, usually at a width you pick by eye, and you see the menu at that width. A real phone reports a different width, changes it when turned sideways, and may show the page with its own zoom. A setting you leave alone for the phone can carry over from desktop, so the desktop list can reach the phone unchanged. Nothing in the builder tells you which width is the one that switches the menu.

• Drag the browser window narrower, slowly. At what width does the menu change?
• Open the builder's phone view and check that the menu is not still set to the desktop layout.
• Look for a long stacked list where a single menu button should be.
• Tap the menu button on a phone. Does the list open, or does nothing happen?
• Note the width where the switch happens and compare it with the phone width you expected.

Divi's responsive controls are built so that you style once and adjust where needed. A desktop choice fills the tablet and phone views until a setting is changed for that size. That helps most of the time, and it is also how a menu ends up as a full list on a phone: the desktop display of the links was never switched off for the small size. An owner who checks only the desktop view sees the intended design, while a phone reads the inherited one.

Width is the first fault: the menu switches at a width that does not match the phones your visitors use, so a common phone sits on the wrong side of the change. The switch point is the second: the menu turns into a button at the right width, but the list it opens was styled for desktop and sits outside the screen. The tap is the third: the button appears, and a tap does nothing, which usually means another element covers the button or the phone settings hide the open panel.

Test them in order. First drag the window narrower and note the width where the layout changes. Then open the list at that width and check that it fits the screen, including the last link at the bottom. Last, tap the button on a phone, because an emulated tap is a mouse click and cannot show a covered button. Write down each result as a width, a fit or a tap, so the next person can repeat it.

The builder preview is built for editing, and it may not match the page a phone loads. It resizes the frame you see, and it does not always reproduce a phone's own zoom, touch handling or fonts. A tap in the builder can pass while a real tap fails, and a layout that looks right at one width can break at the width a phone actually uses. Check the menu on the public page, outside the builder, at the phone widths your visitors use.

Updating the theme, adding a page to the menu or changing a desktop style can move the phone view without a visible change on desktop. After each change, open the public page at a phone width, tap the menu and compare where it stops or breaks with the last run. Keep the phone widths fixed between runs, so a difference comes from the change.