mpv:// protocol broken when launched from web browsers due to URL normalization

mpv Information

mpv v0.41.0 Copyright © 2000-2025 mpv/MPlayer/mplayer2 projects
 built on Feb 11 2026 22:07:06
libplacebo version: v7.360.1
FFmpeg version: n8.0.1 (runtime n8.1)
FFmpeg library versions:
   libavcodec      62.11.100 (runtime 62.28.100)
   libavdevice     62.1.100 (runtime 62.3.100)
   libavfilter     11.4.100 (runtime 11.14.100)
   libavformat     62.3.100 (runtime 62.12.100)
   libavutil       60.8.100 (runtime 60.26.100)
   libswresample   6.1.100 (runtime 6.3.100)
   libswscale      9.1.100 (runtime 9.5.100)

Other Information

- Linux version: Arch Linux
- Kernel version: 6.18.9
- Window Manager and Version: sway 1.11 (wlroots/wayland)
- Source of mpv: Arch extra repo
- Web browser: Mozilla Firefox 148.0.2
- Issue started after the following happened: implementation of mpv:// custom scheme handler in 0.40.0

Reproduction Steps

1. Register mpv as handler for mpv:// URLs (via a .desktop file with x-scheme-handler/mpv and Exec=mpv -- %u see one example below for instance in sample files section)
2. Open a link like mpv://https://example.com/video.mp4 from Firefox by clicking
3. Confirm the protocol handler prompt to use the mpv handler (will be mpv protocol handler in our example for xdg parsed one, or "System Handler" for regular GIO Firefox handling)

Expected Behavior

mpv opens and plays https://example.com/video.mp4
(of course it should network error as this specific example URL doesn't exist in this case but that's expected)

Actual Behavior

mpv receives a mangled URL and fails silently. Browsers conforming to the WHATWG URL Standard normalize the path component of unknown schemes, stripping the colon from the nested protocol. The URL passed to mpv becomes:
mpv://https//example.com/video.mp4
instead of:
mpv://https://example.com/video.mp4

This causes mp_split_proto in stream/stream_mpv.c to fail to detect a protocol in the path, since it looks for :// which is no longer present.
xdg-open mpv://https://example.com/video.mp4 works correctly because it passes the URL as-is without parsing it.

Suggested Fix

In stream/stream_mpv.c, after stripping the mpv:// prefix, detect and repair the missing colon before //. A pattern like ^[a-zA-Z]+// is unambiguously a mangled protocol and can be normalized to scheme://.

Additionally, etc/mpv.desktop adds mpv to X-KDE-Protocols but does not add x-scheme-handler/mpv to MimeType, so the handler isn't registered on non-KDE freedesktop environments. You can ignore this though as this is a different issue but related as it explains the custom .desktop file needed in my case.

Log File

mpv-protocol-log.txt

Sample Files

mpv-protocol.desktop

[Desktop Entry]
Type=Application
Name=mpv protocol handler
Exec=mpv -- %u
MimeType=x-scheme-handler/mpv;
NoDisplay=true

(you may need either to register in the xdg db: xdg-mime default mpv-protocol.desktop x-scheme-handler/mpv or GIO: gio mime x-scheme-handler/mpv mpv-protocol.desktop)

I carefully read all instruction and confirm that I did the following:

• I tested and confirmed that the issue exists with the latest release version or newer.
• I provided all required information including system and mpv version.
• I produced the log file with the exact same set of files, parameters, and conditions used in "Reproduction Steps", with the addition of --log-file=output.txt.
• I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
• I attached the full, untruncated log file.
• I attached the backtrace in the case of a crash.

Start in stream/stream_mpv.c, especially mp_split_proto and the code that strips the mpv:// prefix. Reproduce the Firefox launch with a registered handler and compare it with xdg-open, then verify that a normalized nested URL reaches the underlying protocol intact and that existing protocol handling still works.