Home button (and after delete pad redirect) redirect to domain root even when etherpad is hosted behind a reverse proxy with a URL prefix

[thpiron]

Describe the bug
When Etherpad is deployed behind a reverse proxy under a URL prefix, the pad toolbar home button ("Back to home") redirects to the domain root instead of the Etherpad home page under that prefix.

Example:

• Etherpad home is served at /etherpad/
• A pad is opened at /etherpad/p/testpad
• Clicking the home button redirects to /
• Expected destination is /etherpad/

This appears to be a client-side navigation bug in the home button implementation, not a reverse-proxy header configuration issue.

To Reproduce
Steps to reproduce the behavior:

1. Deploy Etherpad behind a reverse proxy under a URL prefix such as /etherpad
2. Configure the proxy so Etherpad otherwise works correctly under that prefix (X-Proxy-Path: /etherpad)
3. Open a pad, for example /etherpad/p/testpad
4. Click the toolbar home button ("Back to home")
5. Observe that the browser is redirected to / instead of /etherpad/

Expected behavior
The home button should redirect to the Etherpad home page under the same public prefix, for example /etherpad/, not to the domain root.

Screenshots
If applicable, add screenshots to help explain your problem.

Server (please complete the following information):

• Etherpad version: 3.3.3
• OS: docker
• Node.js version (node --version): version in https://hub.docker.com/layers/etherpad/etherpad/3.3.3/images/sha256-776e8d66b967c756771f681ae6f887f3ce3e831269728cddb0ab2537e23d1fa8
• Is the server free of plugins: yes
• Are you using any abstraction IE docker? [e.g. Docker / reverse proxy / ingress]
• docker with custom reverse proxy (I can set up with nginw with needed, but the "bug" is in frontend)

Desktop (please complete the following information):

• OS: linux, MacOS, windows
• Browser [e.g. Firefox, Chrome]; Firefox, safari and edge (respectively)
• Version [e.g. 128]

Smartphone (please complete the following information):
not tested on smartphone

** suspected bug
Client-side is not prefix-aware.

The current implementation in src/static/js/pad_editbar.ts is:
https://github.com/ether/etherpad/blob/develop/src/static/js/pad_editbar.ts#L485C1-L486C7

this.registerCommand('home', ()=> {
  window.location.href = new URL('../..', window.location.href).href
})

On my instance: 
in the js console:
window.location.href is set to "https://<mydomain>/etherpad/p/testpad" 
so 
new URL('../..', window.location.href).href  is "https://<mydomain>/"

[AkprasadoP]

I’d like to work on this.

My proposed fix is to change the Home command’s relative URL from ../.. to ... From /etherpad/p/testpad, that resolves to /etherpad/, while it still resolves to / for a standard /p/testpad deployment.

I’ll also add a regression test for a proxied /etherpad prefix, covering both the Home button and the redirect after pad deletion if they share the same command/path.