Preface
In my previous article, I introduced the detailed steps on how to deploy a web-based retro game emulator based on emulatorjs Docker (see article:Deploying Web-based Retro Game Emulator Using Docker Based on emulatorjs), but in the end, there was an issue left that greatly affects the gaming experience, which is the unreasonable default key configuration: the Up, Down, Left, and Right directional keys are controlled by the ↑ ↓ ← → keys on the right side of the full keyboard, while the conventional AB buttons (jump, shoot) are pressed by the X and Z keys on the far left of the full keyboard. For the vast majority of people, the left hand controls direction, and the right hand controls jump and shoot. Doesn't this mean playing cross-handed? How can anyone tolerate this?
So I did some research and tinkering. First, I wanted to directly modify the default configuration by modifying the key mapping in the emu-main.js file, but failed. It seemed that I also needed to modify the loading order of emu-main.js and emulator.js in the loader.js file, making emulator.js load before emu-main.js. I studied it for a long time but couldn't figure it out, fully exposing my disadvantage of not having a programming background... So I had to change my approach, starting from the perspective of the profile configuration file, and finally solved this problem.
Approach
By default, when you use a browser to access the front-end game web page, if you enter the configuration interface of the RetroArch emulator via the F1 key, configure it once through the ”Settings”-“Input” option, and save it, other games can also use this key setting. However, the premise is that you access it through the same browser, because the configuration file (retroarch.cfg) is bound to the browser (actually, also to the accessed URL; strictly speaking, it should be bound to both the browser and the accessed URL). Therefore, as long as the configuration file is not only stored in one browser ”locally” but can also be ”synchronized” to different browsers on the same machine, or even different browsers on different machines, key configuration roaming can be achieved. So how do we solve this key problem? That is the profile (configuration file).
[VIP]
profile (Administrator Settings)
I mentioned the profile management page of the emulatorjs management console in my previous article:

Here you can create new accounts and manage the configuration files corresponding to the accounts. For example, enter guest for both username and password in the red box at the bottom of the image above, and then click Create Profile on the right to create a guest account under default:

Click the guest account in the red box above to enter its configuration file interface:

In the image above, the states folder stores game saves, and retroarch.cfg is the file that stores key configurations.
Game Front-end Page Settings
Key Configuration Synchronization
The settings in the previous section are in the management console interface, which requires the administrator to create accounts for different users in advance, while the specific games are on the front-end web page:

Click the button in the red box in the upper left corner of the game front-end home page, and the interface after entering is as follows:

Enter the username and password of an existing account (for example, guest, guest) in the red box in the upper left corner of the image above, and then click login to log in:

The image above shows the interface after guest logs in. ”Push to Server” in the upper right corner uploads the configuration file of the guest account in the local browser to the game server, while ”Pull from Server” downloads the configuration file of the guest account from the game server to the current browser, so ”Push to Server” and "Pull from Server" are the ways to achieve key configuration roaming. Push the configuration of the corresponding account to the game server on an already configured browser, and then log in with the same account on other browsers and pull the configuration down.
Default Keys
In fact, the default keys are the configuration corresponding to the default user:

Still on the initial page, before logging in with a specific account, the configuration file in the red box at the bottom left is the configuration file of the default user:

Follow the steps shown in the image above:
Step 1: Click the DL Full Backup button to download all configuration files corresponding to the current browser (including the default user) to the local machine.
Step 2: Use the Upload Full Backup button to upload the configuration file just saved to overwrite the original configuration.
Step 3: Access the front-end page in any browser, re-enter this interface (without logging into a specific account), and then click the Pull Default Config button at the very top to download the default user configuration.
[/vip]
So in fact, it is just like logging into a specific account and then pulling the configuration. The default user just pulls the configuration without logging in, so it doesn't actually achieve modifying the default configuration at the underlying level, but rather indirectly achieves it through configuration file synchronization.