←back to thread

PSA Google Chrome pushed a breaking change in custom protocol handlers this week

11 points nikanj | 3 comments | 22 Oct 24 08:39 UTC | HN request time: 0.615s | source

Trying to save lots of time we wasted debugging this issue: If you have built an app around a custom protocol (i.e. oursoftware://do_cool_thing?callback=http://coolthingdone.com ), the roll-out of Chrome M130 breaks those URLS ( https://issues.chromium.org/issues/374691247 ). Obviously Edge and similar Chromium-based browsers are also affected

This is by design. Unless you are able to convince Google to roll back the change, you need to push an emergency update of your installer to register a different URL scheme.

Just wanted to give everyone a heads up, because this caught our support teams by surprise

Show context
jiripospisil ◴[22 Oct 24 11:24 UTC] No.41913205[source]▶
For context this is indeed a breaking change but a change that brings Chromium in line with the URL spec and other engines. If your URLs are suddenly broken, it means they were invalid the whole time and functioned in Chromium due to bugs in their URL parser.

From the linked issue, the URL "customprotocol://https://example.com/test" starts with // after the scheme so it gets parsed as URL protocol=customprotocol: hostname=https port=<empty> pathname=//example.com/test. When you click the link, the browser will open "customprotocol://https//example.com/test" without the colon after "https" because an empty port is omitted (try opening https://example.com: in your browser).

Another example from the thread is "windx://host:scs/<port>;secure/MIS_VL_WINDX/v1/<sid>". This is invalid because it gets parsed as protocol=windx: host=host port=scs. "scs" is not a valid port number.

What if you want the previous behavior? Make sure the part after scheme doesn't start with //. In that case, the string will not be parsed as URL at all and just passed along.

1. customprotocol:https://example.com/test (protocol=customprotocol: hostname=<empty> pathname=https://example.com/test

2. windx:host:scs/<port>;secure/MIS_VL_WINDX/v1/<sid> (protocol=windx: hostname=<empty> pathname=host:scs/<port>;secure/MIS_VL_WINDX/v1/<sid>

replies(1): >>41913376 #
1. nikanj ◴[22 Oct 24 11:55 UTC] No.41913376[source]▶
This does bring Chromium in line with the URL spec, but Firefox still works properly with those callback links. Not sure which other engines you are speaking of, to my knowledge there really aren't any other viable Windows desktop browsers.

From an end-user point of view, Firefox remains not broken and Chromium broke things in the latest update. Your enterprise IT department cares very little about the standards compliance of the browser, they just want to avoid unplanned emergency upgrades if possible

On the server side, this is dead-easy to fix. For example register customprotocol64: and pass all your data in a base64 encoded blob, to stop the browser from mangling it.

Unfortunately every single offered workaround starts with deploying an upgraded version of your desktop application, so it understands the fixed link format. The challenge is not making the URLs spec compliant, it's getting the massive install bases upgraded to a version that properly parses the new URL format.

I wanted to push out this PSA to save everyone's time, because at least we spent quite a bit of time chasing server-side and templating engine issues, before we realized the link gets mangled by the browser after the data from the server has been rendered by the templating engine.

PS Better just bite the bullet and start planning those emergency upgrades now, the odds of the Chromium team restoring non-standards-compliant behaviour to fix thousands of enterprise apps is essentially zero

replies(1): >>41916150 #
2. jiripospisil ◴[22 Oct 24 16:47 UTC] No.41916150[source]▶
> This does bring Chromium in line with the URL spec, but Firefox still works properly with those callback links. Not sure which other engines you are speaking of, to my knowledge there really aren't any other viable Windows desktop browsers.

Hm, you're right, they're still working on it (https://bugzilla.mozilla.org/show_bug.cgi?id=1876105). Is it Safari then? I don't remember and don't have a way to test it right now. Obviously Safari is not something you care about on Windows anymore.

> On the server side, this is dead-easy to fix. For example register customprotocol64: and pass all your data in a base64 encoded blob, to stop the browser from mangling it.

You don't need to obfuscate it that much, just not start with // and then the rest can be still human readable/inspectable.

> Unfortunately every single offered workaround starts with deploying an upgraded version of your desktop application, so it understands the fixed link format. The challenge is not making the URLs spec compliant, it's getting the massive install bases upgraded to a version that properly parses the new URL format.

I agree. I'm a little bit surprised that they just dropped this and there wasn't any "grace" period where the browser would parse the URL as before but complained loudly in logs/console.

> PS Better just bite the bullet and start planning those emergency upgrades now, the odds of the Chromium team restoring non-standards-compliant behaviour to fix thousands of enterprise apps is essentially zero

It wouldn't be unheard of. If a big important Google customer complained enough, they might release a patch version with the kill switch turned on (base::kStandardCompliantNonSpecialSchemeURLParsing).

replies(1): >>41916726 #
3. nikanj ◴[22 Oct 24 17:43 UTC] No.41916726[source]▶
> You don't need to obfuscate it that much, just not start with // and then the rest can be still human readable/inspectable.

Fool me once, shame on you. Fool me twice, shame on me. I'll never again trust Chrome to not "help" with custom URLs