webcompat / web-bugs

A place to report bugs on websites.
https://webcompat.com
Mozilla Public License 2.0
730 stars 63 forks source link

dlive.tv - Poor user experience on the website #112617

Open sv-calin opened 1 year ago

sv-calin commented 1 year ago

URL: https://dlive.tv

Browser / Version: Firefox Nightly 108.0a1-20221019083142 Operating System: Android 11 (OnePlus 6 A6000) Tested Another Browser: Yes Chrome

Problem type: Something else Description: Poor user experiece - random behaviour on the website Steps to Reproduce:

  1. Go to https://dlive.tv
  2. Browse on the website. (e.g. Click on the home button (dlive logo) while on a live stream video, click back arrow after opening search menu, check the elements on the header etc.)
  3. Observe the behaviour.

Expected Behaviour: The elements on the website load correctly and the functionalities work properly.

Actual Behaviour: Page elements/content dissappear and appear randomly whenever the page is getting refreshed and the buttons/links do not work properly.

Performance Profile⁩: https://share.firefox.dev/3D9bQ4F

Notes:

  1. Screenshot provided
  2. Reproducible on Firefox Release as well
  3. Not reproducible on Chrome
  4. There's not really a pattern on how these issues occur, once the page starts to break the buttons/links do not work properly

Watchers: @softvision-oana-arbuzov @softvision-raul-bucata @sv-calin

View the screenshot Screenshot
Browser Configuration
  • None

From webcompat.com with ❤️

sv-calin commented 1 year ago

Moving to needsdiagnosis.

[qa_42/2022]

wisniewskit commented 1 year ago

Their mobile site is completely broken right now in Firefox (works in Chrome), so let's figure that out first.

On desktop in responsive design mode, I see the page reloading as it loads (the network requests in the devtools are cleared and such), breaking a bunch of stuff. I set a breakpoint in one of their scripts so that it would trigger before the unloading, then ran window.onbeforeunload = () => { debugger }; in the console, resumed, and checked the resulting stack trace to find out what's triggering it:

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

Weird. It looks like that's called from here, so they're redirecting to dlive://dlive.tv:

            {
              key: 'mounted',
              value: function () {
                Object(g.d) ('dlive://dlive.tv', !this.$route.query.gxc)
              }
            },

But I don't really understand why Firefox would be leaving the page for that, because dlive isn't a valid protocol, and Firefox claims to prevent the navigation. It looks like it only blocks the first of the two rapid-fire href changes, as when I comment out the second one, everything seems to work.

So while this is technically the site's own error, and I have no idea why they would go out of their way to change the location twice like this, it's a webcompat issue. I've filed bz1840731 to figure out what to do here. There isn't much else we can do here short of that being addressed, since we can't override the location.href setter due to it being locked down, so no easy site intervention can be written.