Closed Bug 1472139 Opened 6 years ago Closed 5 years ago

Loading spinner displays at end of video on Twitter (Windows 10) and Reddit (all)

Categories

(Core :: Audio/Video: Playback, defect, P3)

57 Branch
x86_64
All
defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- wontfix
firefox61 --- wontfix
firefox62 --- wontfix
firefox63 --- wontfix
firefox64 --- wontfix
firefox65 --- wontfix
firefox66 --- wontfix
firefox67 --- fix-optional
firefox68 --- affected

People

(Reporter: oanaarbuzov, Unassigned)

References

(Regression, )

Details

(Keywords: regression, Whiteboard: [webcompat])

Attachments

(3 files)

Attached file AffectedArea.txt
Steps to reproduce:
    1. Navigate to https://twitter.com/FirefoxNightly/status/961156943183302656 
    2. Wait until the video ends.
    3. Observe “Play” button.
       
Expected Behavior:
No loading spinner is displayed.
 
Actual Behavior:
A loading spinner is displayed above the “Play” button, until clicking the button.

Note:
    1. Reproducible on Firefox 58.0.2 Release.
    2. Not reproducible on Chrome 64.0.3282.137. 
    3. Screenshot attached.
    4. Affected area attached.
Attached image LoadingOverPlayBtn.gif
regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=f2f6cc2e67cab9ebe4c0f71bd35ad04c740a8d91&tochange=b7429873f639fca4f386639804f6e40d4a704f20

regressed by: Bug 1405025
Blocks: 1405025
Has Regression Range: --- → yes
Has STR: --- → yes
Component: General → Audio/Video: Playback
Keywords: regression
Product: Firefox → Core
Version: 63 Branch → 58 Branch
Version: 58 Branch → 57 Branch
Annoying UX breaking:
After the problem appears, clicking the blue play button to replay does not react.
Can this be reproduced in Nightly ?
can't reproduce here...
Current version of Firefox is 61
can't reproduce in 60 either
See Also: → 1472213
I can reproduce this on Nightly63.0a1
Build ID 	20180629100106
User Agent 	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0


If you don't, try
Steps to reproduce:
    1. Navigate to https://twitter.com/FirefoxNightly (not required logged in)
    2. Scroll to the video in to view
    3. Video will start to play back automatically. Wait until the video ends.
    4. Observe “Play” button.
Such spinner is handled by the website anyway. So the issue would need to be fixed by Twitter.
I can't reproduce on Ubuntu 18.04 but can on Windows 10 with latest Nightly.

It doesn't happen on Chromium 67 on Windows 10.

It still happens with a spoofed Chrome user agent.
Summary: Loading spinner displayed above the “Play” button → Twitter video loading spinner displayed above the “Play” button on Windows 10
I can still reproduce on today's Nightly on Windows only. Mike, jya says that this is a website issue and not a Firefox issue, do we have contacts at Twitter we can ping to get this fixed on their end?
Flags: needinfo?(miket)
Yep we do. Ideally we know a bit more about this, but we can ping them to get a conversation started.

(In reply to Alice0775 White from comment #2)
> regression window:
> https://hg.mozilla.org/integration/autoland/
> pushloghtml?fromchange=f2f6cc2e67cab9ebe4c0f71bd35ad04c740a8d91&tochange=b742
> 9873f639fca4f386639804f6e40d4a704f20
> 
> regressed by: Bug 1405025

Jean-Yves, did Bug 1405025 have any script-observable effects? Twitter might have been relying on some media event or something (not sure...)


Adam, can you reach out to Twitter?
Flags: needinfo?(miket)
Flags: needinfo?(jyavenard)
Flags: needinfo?(astevenson)
(In reply to Mike Taylor [:miketaylr] (62 Regression Engineering Owner) from comment #11)
> Yep we do. Ideally we know a bit more about this, but we can ping them to
> get a conversation started.
> 
> (In reply to Alice0775 White from comment #2)
> > regression window:
> > https://hg.mozilla.org/integration/autoland/
> > pushloghtml?fromchange=f2f6cc2e67cab9ebe4c0f71bd35ad04c740a8d91&tochange=b742
> > 9873f639fca4f386639804f6e40d4a704f20
> > 
> > regressed by: Bug 1405025
> 
> Jean-Yves, did Bug 1405025 have any script-observable effects? Twitter might
> have been relying on some media event or something (not sure...)

yes.. events were fired in a different order, waiting followed by seeking.

the waiting event outside a seeking context was used as a trigger by YouTube to determine if the machine was too slow to play the content as this is a (non-standard) behaviour of Chrome.

So we made the waiting event be fired after seeking which was the right thing to do anyway.

At a guess I would assume that twitter is doing a similar workaround as YouTube because it worked with Chrome.
likely listening to the waiting event and take that as a clue to display the spinner, not listening to further event maybe progress or timeupdate that it's no longer listening to more data.

it's a guess only
Flags: needinfo?(jyavenard)
twitter contacted.
Flags: needinfo?(astevenson)
Looking into it. We do expect a seeked/playing after waiting.
Too late to fix in 63. We could still take a patch for 65 and potentially for 64.
Seeing that this is a site issue I'm closing it as WONTFIX. I can also not reproduce on Mac, though it does seem on comments like it only reproduces in certain conditions. Hopefully it's been fixed by Twitter.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
Still easy to reproduce using original STR with Nightly 66 on Windows 10 (Ubuntu 18.10 unaffected).

Some Reddit videos are also affected with the same regression window, both on Windows 10 and Linux. At the end of the video an orange loading spinner appears (Chromium unaffected).

Example: https://www.reddit.com/r/reallifedoodles/comments/a725yi/

Reopening since multiple sites and platforms are affected.

Status: RESOLVED → REOPENED
OS: Windows 10 → All
Resolution: WONTFIX → ---
Summary: Twitter video loading spinner displayed above the “Play” button on Windows 10 → Loading spinner displays at end of video on Twitter (Windows 10) and Reddit (all)

On Windows Firefox firing a 'waiting' event at the end of the view before 'ended'. On Mac the waiting event does not fire. Twitter expects a 'playing' or 'seeked' to signal the end of buffering. We can add something in 'ended' and 'paused', but we don't have this problem in any other browser, AFAIK.

Nils, could you please find someone to look into this for our 67 soft freeze (Mar 11)?

Flags: needinfo?(drno)

I see no relation with bug 1405025.

No longer regressed by: 1405025

(In reply to Greg Kindel [:twitter] from comment #20)

On Windows Firefox firing a 'waiting' event at the end of the view before 'ended'. On Mac the waiting event does not fire. Twitter expects a 'playing' or 'seeked' to signal the end of buffering. We can add something in 'ended' and 'paused', but we don't have this problem in any other browser, AFAIK.

Could you please detail on what even you are expecting to be fired that would cause the spinner to stop being displayed?

If using MSE, it's entirely possible for the waiting event to be fired followed by ended should the player reached the end of the source buffer content before MediaSource.endOfStream got called. This will result from a transition to "waiting" into "ended" directly.

Flags: needinfo?(gkindel)

(In reply to Jean-Yves Avenard [:jya] from comment #23)

If using MSE, it's entirely possible for the waiting event to be fired followed by ended should the player reached the end of the source buffer content before MediaSource.endOfStream got called. This will result from a transition to "waiting" into "ended" directly.

Good on this end. The buffering indicator is now cleared by the player on ended.

Flags: needinfo?(gkindel)

I have never noticed this issue with Reddit and now Twitter handles this.

Status: REOPENED → RESOLVED
Closed: 5 years ago5 years ago
Resolution: --- → WORKSFORME
Flags: needinfo?(drno)

(In reply to Jean-Yves Avenard [:jya] from comment #22)

I see no relation with bug 1405025.

Bug 1405025 is the regressing bug as per Comment 2 and I previously confirmed this myself with mozregression in Comment 18.

Regressed by: 1405025
See Also: → 1543059
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: