STR: 1. Load http://stuffadventure.com/ (which was linked from the Chrome Experiments home page: https://www.chromeexperiments.com) RESULT: The site shows a progress spinner and loads a bunch of js files, but never finishes loading in Firefox. It loads correctly in Chrome.
stuffadventure.com still fails to load in Firefox Nightly 52. It loads correctly in Chrome and Edge.
status-firefox52: --- → affected
I bisected this problem to the following pushlog in Nightly 31 build 2014-03-23: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c148f0b0c8b4&tochange=c3b840de1f7b However, I am now able to intermittently load the site in Nightly 52 after about 3-5 page reloads. Once loaded, the page will continue to successfully reload until I clean my browser cache. But I do think the above pushlog is the correct regression range because I ran two bisections and they both landed on that same pushlog.
OS: Unspecified → All
Summary: Chrome Experiment "Stuff: The Abandoned Land" stuffadventure.com never finishes loading in FF → Chrome Experiment "Stuff: The Abandoned Land" stuffadventure.com never finishes loading in Firefox
cpearce, could this bug be a regression from your audio preroll change in bug 984698? Your changeset was in the regression range from comment 2. This web game usually stalls when loading game assets (if the browser cache is empty). The HTTP requests to one or more mp3 files (and only ever mp3 files) appear to never receive an HTTP response, but the mp3 files load fine in their own tab. When the page loads correctly, it logs "Map loaded" and "Sound Loaded" to the devtools console. When the page stalls, it only logs "Map loaded". In a debug build, the page load triggers multiple "Unimplemented function NotifyDataArrived" NS_WARNINGs from mp3 bug 1169485.
In the failure cases, we're not dispatching "canplay" all audio elements. In the success case, we are dispatching "canplay" to all except for video/intro.mp4. If I dispatch "canplay" when we reach "loadeddata", we load the demo. So I expect we need to tweak our logic to make "canplay" more optimistic.
Component: General → Audio/Video: Playback
Or they could fix their JS by using the proper preload value and not relying on a particular event that won't be fired if the default preload=metadata is set.
I think jwwang fixed this in bug 1317201. Should be fixed in Firefox 53.
I verified that Nightly 53 is fixed and Aurora 52 is still broken. I assume we don't plan to uplift bug 1317201 to Aurora 52 or Beta 51, so I'll mark those releases as wontfix.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
status-firefox50: --- → wontfix
status-firefox51: --- → wontfix
status-firefox52: affected → wontfix
status-firefox53: --- → verified
Depends on: 1317201
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.