1949195 - Firefox removes at sign (@) from UDP links for VLC video player

Status: RESOLVED FIXED

(Core :: Networking, defect, P3)

Description

[lysek.jiri]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:135.0) Gecko/20100101 Firefox/135.0

Steps to reproduce:

Our web-app system generates URLs for UDP multicast video streams that are opened in VLC video player. The URL looks like this: udp://@239.2.3.10:1234 These URLs contain at sign (@) that is being removed by the browser (from Firefox 133) although in the HTML code it is present. This happened recently, it worked on older versions of Firefox.

The meaning of IP address behind @ means the UDP multicast group that should be registered by VLC to receive UDP multicast packets. Before the @ sign there is usually nothing which means that VLC should listen on all local interfaces.

Example of URL with @: https://jsfiddle.net/c74z20Lx/ Hover the mouse over the generated URL and see that the @ was removed.

Description of multicast UDP URLs: https://www.advanceddigital.com/blog/using-vlc-multicast-unicast-udp-streams/

The problem is also reported and described here: https://forum.videolan.org/viewtopic.php?t=165823

Actual results:

The VLC is opened, but the @ is not passed to it so the video does not play.

Expected results:

It should work like in older Firefox releases: open VLC with full URL including the @ and play video. It worked on version 132.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[lysek.jiri]

The VLC player is obviously registered as udp:// protocol handler.

Comment 3

[lysek.jiri]

(In reply to BugBot [:suhaib / :marco/ :calixte] from comment #1)

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

It is probably related to some URL sanitization and custom protocol handlers.

Comment 4

[Tom Schuster]

Parsing udp://@239.2.3.10:1234 as udp://239.2.3.10:1234 is correct per WhatWGL URL standard. We have a bypass list for URLs that don't parse correctly though.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

:edgul, since you are the author of the regressor, bug 1603699, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 6

[edgul]

In about:config, if you add udp to the network.url.simple_uri_unknown_schemes pref, does that help?

Comment 7

[lysek.jiri]

(In reply to edgul from comment #6)

In about:config, if you add udp to the network.url.simple_uri_unknown_schemes pref, does that help?

Yes, it works as expected after adding udp to that configuration.

Btw I found another SW affected by this: https://portal.microfocus.com/s/article/KM000037425?language=en_US

Comment 8

[Valentin Gosu [:valentin] (he/him)]

(In reply to lysek.jiri from comment #7)

Btw I found another SW affected by this: https://portal.microfocus.com/s/article/KM000037425?language=en_US

This one appears to have been resolved, so I don't think there's any action needed on our part.

(In reply to lysek.jiri from comment #0)

Description of multicast UDP URLs: https://www.advanceddigital.com/blog/using-vlc-multicast-unicast-udp-streams/

Documentation is here:
https://docs.videolan.me/vlc-user/desktop/3.0/en/advanced/streaming/udp_url.html

The main question is whether this scheme is common & important enough to ship through remote settings.

Comment 9

[lysek.jiri]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #8)

Documentation is here:
https://docs.videolan.me/vlc-user/desktop/3.0/en/advanced/streaming/udp_url.html

The main question is whether this scheme is common & important enough to ship through remote settings.

It is definitely related to one certain application - the VLC - which kind of hacked the URL string (if I understand it correctly) but I cannot speak for the VLC creators, I am not anyhow related to them. On the other hand the VLC is widely used and UDP video stream can be produced by any IP camera...

Our use-case is to receive raw video stream from cameras/sensors/drones inside a closed network. My opinion is that browser should pass the URL as-is to the external application if that protocol is registered to be handled outside of the browser - maybe it could ask whether to parse the URL or not when registering external protocol handler for the first time. Maybe the correct way would be to not use the href attribute and open external application using another way (some JS maybe?).

Comment 10

[Randell Jesup [:jesup] (needinfo me)]

There is a spec for how URLs are supposed to be constructed; it seems like VLC decided to hack something that works-in-chrome instead of finding a way to do it within the spec. @ is only for delineating user:password from host:port.

Probably they should have used something like "[server_addr|][:server_port]@[bind_addr][:bind_port]" i.e. udp://@239.2.3.10:1234

This would have parsed as user=* host=239.2.3.10 port=1234

However, they didn't, so now we have to deal with the fallout. We should contact the VLC people as well.

We may want to open a webcompat bug on this - tom

Comment 11

[Thomas Wisniewski [:twisniewski]]

I suspect that perhaps we should just do whatever Chrome is doing in this specific case (which I'm presuming is to just send the href as-is), unless there is a compelling reason to not do so?

Comment 12

[Thomas Wisniewski [:twisniewski]]

James and Dennis are likewise pessimistic about VLC changing this, and that we might as well try to align the spec with Chrome's behavior here. I'm guessing that Safari is also broken?

Comment 13

[lysek.jiri]

(In reply to Thomas Wisniewski [:twisniewski] from comment #12)

James and Dennis are likewise pessimistic about VLC changing this, and that we might as well try to align the spec with Chrome's behavior here. I'm guessing that Safari is also broken?

The Chrome/Chromium browser also has this issue recently...

I made a new fiddle that shows variants of URL for UDP video stream: https://jsfiddle.net/gvh5u2rp/

Currently none of the URLs work universally (in FF and Chrome browsers), few weeks ago the first two were OK in FF and in Chrome. I also included the *@ version proposed by Randell Jesup a few posts before but that does not work as the VLC does not understand it (his formatting is broken but I suppose that italics is result of using *). What works in FF is udp://:1234@239.23.40.88:1234 variant but that does not work in Chrome.

I find interesting that even the variant udp://:@239.23.40.88:1234 is parsed as udp://239.23.40.88:1234 because it might be useful to pass empty username and password...

Comment 14

[Valentin Gosu [:valentin] (he/him)]

I think we can add this to the exception list in remote settings. I assume schemes like ed2k have an even smaller adoption, and we have an exception for that. 🙂
But long term I think VLC needs to update their parser to accept functionally equivalent URLs such as udp://:@239.23.40.88:1234 vs udp://239.23.40.88:1234

Comment 15

[Valentin Gosu [:valentin] (he/him)]

This was fixed by deploying the exception through remote-settings.
Once the sync happens, clients should be using the old parser for udp URLs.
You can use this URL to check:
https://jsdom.github.io/whatwg-url/#url=dWRwOi8vOkAyMzkuMjMuNDAuODg6MTIzNA==&base=YWJvdXQ6Ymxhbms=

Comment 16

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1603699

Comment 17

[Valentin Gosu [:valentin] (he/him)]

All of these versions should get the fix via remote-settings.