1840731 - Changing document location to invalid protocol twice in rapid succession is not ignored

Status: NEW

(Core :: DOM: Window and Location, defect, P2)

Description

[Thomas Wisniewski [:twisniewski] [on PTO until Sep.9]]

If one visits the mobile page of https://dlive.tv/ (for instance, in the responsive design mode with a Chrome device and user-agent string selected), the page does not load properly. For whatever reason, as the page loads their scripts try to alter window.location.href to dlive://dlive.tv twice in rapid succession:

        return a &&
        (
          window.location.href = e,
          window.location.href = e,
          setTimeout((function () {
            void 0 !== t &&
            t()
          }), 1500)
        ),

Commenting out one of those two window.location.href lines fixes the issue, as Firefox blocks one of them. It ought to be blocking both, which is what Chrome seems to do, and why the page loads on Chrome for Android.

Either way this is a webcompat issue that's breaking a site outright, even if the site seems to be going out of their way to do something ill-conceived.

Comment 1

[Andreas Farre [:farre]]

Simon, I'm trying to gauge how bad this webcompat issue is. Do you have an opinion?

Comment 2

[Thomas Wisniewski [:twisniewski] [on PTO until Sep.9]]

FWIW, I wouldn't suspect it would be widespread, as I've never seen a site try to set the location twice in rapid succession like this. However, it utterly breaks a site, so for the webcompat team it is a p2. It also trivially defeats the redirection blocker and has Firefox vaguely prompt the user if they want to leave Firefox to view the page content in another app, which isn't a pleasant UX.

Comment 3

[Simon Pieters [:zcorpan]]

Checking httparchive for resources setting window.location.href twice:

SELECT page, url FROM `httparchive.response_bodies.2023_06_01_desktop` 
WHERE REGEXP_CONTAINS(body, r'(window\.location\.href\s*=\s*[a-zA-Z_]+[,;]\s*){2}')

81 resources on 76 sites, out of the total 12.8m pages (~0.0006%). Note that some of these have the first line commented out. For the remaining, it's hard to tell if they use an invalid scheme.

Results: https://docs.google.com/spreadsheets/d/1-F1cd1Unx8Nn_5jLAmubQVwCPPIIoeJUskvxBaO1QNQ/edit?usp=sharing

At least the script snippet used on dlive.tv isn't commonly used in httparchive.

Comment 4

[Calin Tanase]

Attachment: header FF vs Chrome.png

Based on the webcompat report, the header does not get displayed at all now.

Environment:
Operating system: Google Pixel 5 (Android 14)
Browser tested: Firefox Nightly 128.0a1-20240528001238 (Build #2016023391) / Firefox Release 126.0.1-20240526221752 / Chrome 125.0.6422.72

Comment 5

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hi Andreas, can you please investigate what's up in our code?

Comment 6

[Andreas Farre [:farre]]

I think I need a little help reproducing this, because I neither see errors in android emulator, Firefox Nightly on my Pixel 7 nor desktop in responsive design mode. What I do see though is Chrome in responsive design on Linux trying to get xdb-open to open something.