feat: debug bar
Implements #459
Adds helpers/debug.js, which provides three public functions:
debugBar(): returns an HTMLElement which consists of a container with inner grid and a series of buttons/widgets arrayed in it. These buttons triggers various functionality, explained below.isDebugBarEnabled(): boolean test of whether the localStorage keymes-debugbar["enabled"]is truetoggleDebug(): writes the state of the debug bar to localStorage and reloads the window, allowing the debug bar to be injected/removed and its settings applied/unapplied on pageload. This is done to show a "clean run" of what the page loads like when the debug bar's block filters are applied or unapplied.
The debug bar allows the user to block or unblock various mods from triggering, irrespective of the user's persistent settings in MES. This allows you to test/troubleshoot various mod interactions without destructively changing your usual settings. Debug filters are stored in a separate namespace.
If the debug bar is enabled, the underlying MES enable/disable state is ignored, and the debug bar's filters take precedence completely. This allows you to test mods you don't necessarily have enabled in your main MES settings.
[!NOTE] Due to their complexity, the mod's granular settings saved in MES are still inherited when in debug mode. You can quickly access the mod's setting page via the debug bar to change these.
Pictured below, the debug bar is sandwiched below the main Mbin navbar and before the content area. An explanation of each widget follows.
Mod selection area
- MES button: opens the MES modal to the page corresponding to the mod currently selected in the dropdown
- Version link: prints the MES version. Clicking this link opens a new tab to the GitHub issue page with the MES version number pre-filled
- Select menu: alphabetized list of all mods, using their internal snake case entrypoint names. Mods are grouped and numbered according to blocked/unblocked state, and the contents of this dropdown are updated whenever a mod's state changes. (In practice, the entire select menu is removed, repopulated, and reinserted).
Button area
- Block/unblock mod: toggles the state of the currently selected mod in the dropdown. This button updates dynamically depending on the underlying state of the dropdown's currently selected index.
- Block all: sets all mods to the blocked state
- Unblock all: sets all mods to the unblocked state
- Apply changes: after new values are saved to localStorage, triggers a page reload. Any change to the state of a mod or mods will highlight this button, indicating that there are unapplied changes
- Anonymize: a checkbox that redacts usernames, thread titles, magazine and instance names, images, and the logged in username with generic/randomized content. Used for mocking the behavior of mods when taking screenshots. Unticking this input reloads the page. This is not intended to be a fully comprehensive anonymization feature, but has about 95% coverage. (Chiefly used on the thread index and inside threads.)
Debug area
- Load time profiling: lists the number of mods loaded, the total time, and any exclusions (such as mods skipped due to requiring login). Provides a naive way of checking if certain mods are significantly adding to load time.
- Icons indicating the number of log notifications at the default, warning, and error levels, respectively
- Expand/collapse button: opens the notifications tray, which is populated with log strings coming from the public
log()function. These are also emitted to the browser console as before. The notifications tray is just an extra debug panel collecting MES-specific events. The notifications tray is limited to 400px and will scroll on the Y axis if the number of notifications exceeds this space.
Provided it is enabled, the debug bar is injected by the main MES script prior to any mods being loaded. When applying mods, load times and notifications are pushed into the debug bar in real time.
[!NOTE] The debug bar is not currently sticky. This could be added, although most use of this bar will involve reloading the page after applying changes, so it is always going to be one of the first things seen on the page.
The notifications panel has some issues specifically on the Tokyo Night theme, which uses non-standard colors for the kbin alert-info and alert-danger levels, despite every other theme using variations of yellow and red.
I've normalized the CSS for each theme and I think they are mostly "pretty good" now. The light themes still have the typical anomalies/eyesores, due to the inconsistent palette and lack of vibrant colors for some alerts (notably with SOLARIZED_DARK). I've also included some duplicate CSS for each theme, because while a few of them share the same colors (particularly in terms of border color), it can be difficult to distinguish which theme is deviating from the main CSS boilerplate, so I chose to explicitly inline the same chunk of CSS for each theme, in case it needs to be changed on a per-theme basis in the future.