1187433 - Bad resize performance on website All of Bach

Status: RESOLVED WORKSFORME

(Firefox :: General, defect, P2)

Description

[Lucas Werkmeister]

To reproduce:

1. Open any All of Bach performance, example: http://allofbach.com/en/bwv/bwv-565/detail/
2. Start the video and switch to fullscreen.
3. Leave fullscreen.
4. Close the video. (X button, top right of the player.)
5. Scroll down the page until the menu appears. Go to “Interview” (on example: “Pulling all the stops”).
6. Open the video.
7. Start the video and switch to fullscreen.

Expected: Regular video playback.

Actual: Fullscreen, but the image is slightly vertically squashed. Entire browser and desktop become highly unresponsive. Video playback turns into slideshow, new frames only arriving intermittently; audio playback, however, remains fluid.
If you’re quick, you can get out of fullscreen with Esc, but I haven’t yet been able to stop the video at this point (closing the tab doesn’t react, or does so too slowly for me to have noticed) – I “fix” this state by switching to a TTY and running `killall firefox`. (When testing this, be sure to already have the TTY logged in and the command typed, so you only need to press Enter. In this state, even logging in (and running your shell init scripts) can take a while.)

This happens reliably if you watch these two kinds of video from All of Bach (performance, then interview) in the same tab without restarting the browser. It doesn’t happen in separate tabs, nor by viewing just the performance or just the interview several times.

I have not encountered this issue on any other websites.

I’ve experienced this issue for some time now (at least half a year, I think). It has survived a browser profile reset, a distro switch (Linux Mint to Arch), and a home directory reset.

Some of my about:config settings that are displayed bold (changed):

- media.fragmented-mp4.{exposed,ffmpeg.enabled,gmp.enabled} = true
- media.mediasource.enabled = true
- media.mediasource.webm.enabled = true
- media.peerconnection.video.h264_enabled = true

I’ll be happy to provide more details if needed.

Comment 1

[Alice0775 White]

I can reproduce the hang with new profile default pref setting.
Nightly eats huge memory, becomes unresponsive due to HDD thrashing.

Comment 2

[Lucas Werkmeister]

Some more information:

- You don’t actually have to start the performance video. Steps 1,5,6,7 are enough to reproduce the issue.
- If you “take a detour” in the page navigation – for example: /detail (performance) → /context (the inside story) → /musicians (interview) – the bug still occurs.
- The problem does not occur if you go from /musicians to /detail, or from /context to /musicians. AFAICT, you need /detail → /musicians.
- If you navigate by entering URLs manually, the bug doesn’t occur.

The bug probably has something to do with their weird scroll-and-replace-the-page-content navigation.

Comment 3

[Xidorn Quan [:xidorn] UTC+10]

This doesn't seem to relate to fullscreen at all. Replace the last step with "start the video and resize the window", this issue could also happen.

Actually it even doesn't seem to relate to HTML5 video. Just doing 1, 5, and then resize the window could see this issue.

Not sure why but it seems there is a large amount of allocation happens inside the resize handler.

Comment 4

[Lucas Werkmeister]

You’re right, I hadn’t noticed that. Fullscreen video seems to produce the effect faster (probably because whatever causes the slowdown is called for each video frame), but if I resize the window enough, I get the same effect.

Comment 5

[Vadym Krevs]

I've got a very similar experience with any 720p or 1080p youtube video.

Comment 6

[Xidorn Quan [:xidorn] UTC+10]

(In reply to Vadym Krevs from comment #5)
> I've got a very similar experience with any 720p or 1080p youtube video.

I've mentioned in comment 3 that the slowness reproducible from comment 0 is neither related to HTML5 video nor fullscreen. This is actually a specific content performance issue case. If you see anything in other websites, please file a new bug for that with its own steps to reproduce, thanks.

Comment 7

[Alice0775 White]

Gecko Profiler log on Nightly44.0a1 e10s with STR comment #0:

http://people.mozilla.org/~bgirard/cleopatra/#report=d63d3bef1c76d94065dce84738a88a710b9aa38a

Comment 8

[Ryan VanderMeulen [:RyanVM]]

The profile in comment 7 looks e10s-ish? I just reproduced this on a current trunk build following the STR in comment 0 and saw a memory usage spike to about 6GB. Even after closing the tab, the sound continued playing for a couple minutes before finally stopping on its own (and memory usage looking saner again).

Comment 9

[Ting-Yu Chou [:ting] (away)]

(In reply to Lucas Werkmeister from comment #0)
> Actual: Fullscreen, but the image is slightly vertically squashed. Entire
> browser and desktop become highly unresponsive. Video playback turns into
> slideshow, new frames only arriving intermittently; audio playback, however,
> remains fluid.

I can't reproduce this on my current trunk build (e10s and non-e10s), do you still see this issue? Thank you.

Comment 10

[Alice0775 White]

No longer reproduce the performance problem on Nightly48.0. and also on the Bad build of comment#1 and comment#7.
It seems the site has changed something.

Comment 11

[Ting-Yu Chou [:ting] (away)]

Jim, by comment 10 I guess we can close this?

Comment 12

[Lucas Werkmeister]

Yes, the website was redesigned a few days ago: https://twitter.com/allofbach/status/705758734962847744
I can’t reproduce it either.

The problem in Firefox probably still exists, but with no way to reproduce it, I guess this issue can be closed, yeah.