I suspect this occurs because the menu in question is a menuBuilder (loads via asynchronous request). If it is such a menu, and it works correctly after adding the aforementioned class, then that may be the solution. As you can see from the code, VaultWiki does not discriminate by class here, but it expects that XenForo is passing an actual element to the xf:reinit event. In this case, XenForo did not pass one; I'm guessing because it could not find the menu contents due to being a menuBuilder that didn't have its Target defined.
In fact, this is the way XF.MenuBuilder is written:
Code:
actionBar: function($menu, $target, handler)
{
var $menuTarget = $menu.find('.js-menuBuilderTarget');
...
XF.activate($menuTarget);
}
XenForo does not test that $menuTarget actually exists, before 'activating' it (and triggering the xf:reinit event). It expects that it does exist.
So here, the bug is either that XenForo expects $menuTarget to exist when it doesn't need to exist for every MenuBuilder, or that it must exist and the menu you've clicked has a bug by not defining one.
Regarding compiled/base.js running on non-wiki pages: this is intentional. The minimal VaultWiki JS must run on pages meeting certain criteria so that our xf:reinit callback is listening, in case an asynchronous event loads wiki content (such as an AJAX preview link), a wiki-related BB-Code needs its Javascript functionality (especially BB-Codes posted via quick reply after the page already loaded), or other cases. The compiled JS won't run on every single page, but certain contexts do trigger it (e.g. BB-Code being rendered).