test: open a menu from whatever state the menubar was left in

[xAlcahest]

Summary

A click on the title of the menu that is already open closes it. Clicking a different title switches, so this only bites when the same menu is asked for twice, which is exactly what language.spec.js does: it clicks .menubar__title--view and waits for the Language item. If the View menu was already up, that click shuts it and the check waits out its whole timeout for an item one click away. On CI run 34678765064 it did wait it out, thirty seconds, with both of the app's beats regular throughout.

openMenu in e2e/lib/menu.js closes whatever is open before it clicks, so the answer no longer depends on what the check before it left behind. runFromMenu goes through it too.

Said plainly: this is a hazard removed, not a cause proved. Nothing in the archived log says the View menu was open at that moment, and nothing can, because the menubar's state is not written down anywhere. What can be said is that this is the only way that failure can be produced from outside the app, and it is gone.

Changes

• e2e/lib/menu.js: openMenu closes an open menu before clicking a title, and runFromMenu uses it.
• e2e/specs/language.spec.js: openLanguage opens the View menu through openMenu.
• e2e/specs/menu-submenus.spec.js: a check that asks for the menu that is already open and finds it open, not shut.
• e2e/wdio.conf.js: the count guard goes from 514 to 515.

How to verify by using the app

Open the Timing menu, then click Timing again: it closes, which is what it should do. Nothing in the app changes here.

Verified on Linux. Full gate green, 87 spec files and 515 tests in 5:48, verdict line GATE GREEN. Proved by a mutation in the build: without the close, that one check goes red and the other four in the file stay green. The first version of the check used two different menus and the mutation left it green, which is how I learned that a different title switches rather than toggles; the check names the same menu twice now.