LanguageNegotiationUrl unnecessarily adds domain to outbound URL's

Thanks for reporting this!

The merge request needs to be created against 11.x (our main development branch); it will be backported to supported versions once committed to 11.x. In some cases the easiest thing to do is close the previous merge request and create a new one against 11.x. Thanks!

I've added test coverage.

As a bonus, it turns out that we've fixed, at least partially, a bug stated in 🐛 Domain-based language negotiation strips "destination" URL query argument, causing BigPipe error Closed: duplicate , so I have had to change a line in BlockUiTest too.

smustgrave → closed merge request !6833

Left 1 small comment on MR

If you are another contributor eager to jump in, please allow the previous poster at least 48 hours to respond to feedback first, so they have the opportunity to finish what they started!

Thanks! I've replied to your comment in the MR.

Been about a month without additional review. Will RTBC but leaving the one thread open.

I'm not sure if this belongs here, or if there needs to be a it's own (new) issue:
I think this fix should apply to the actual domain as well, and not just the destination URL/domain.

Context:
I have a multilingual site that uses sub-domains (and domain-based language negotiation). I want admin users to be able to delete files
The "delete" link that is generated uses the English domain (e.g. website.com/file/123/delete) instead of the sub-domain (e.g. japan.website.com/file/123/delete) the user is currently logged into and clicked the original "delete" link from. So when clicking "delete", it tries to take users cross-domain to complete the process, but stops them with an "access denied" screen since they are not logged in under the English (default) domain.

This is also the same behavior/problem that occurs when trying to use the file_replace module and it's "replace" link.