Can you please clarify the situation here. Is this a regression? Why is it filed under DOM?
Is this a e10s vs. non-e10s issue? Do you perhaps get e10s in post FF47?
Keywords: regression, regressionwindow-wanted
FF 50 on Linux doesn't work with or without e10s.
Firefox: 50.0a1, Build ID: 20160703030210 User Agent Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0 I have tested this issue with the latest Nightly (50.0a1) build on Ubuntu 14.04 x64. I have used the provided test case from bug 1280337 comment 3, and tried to make a regression, but I didn't find a good version where the "loadedmetadata" message is displayed. But using the provided test case from bug 1280337 comment 0, I was able to find a good version where the "loadedmetadata" message is displayed, so I performed a regression. This are the results: Last good revision: c7eedb39844a0131bbd86109a325f402bfa8bf2d First bad revision: 5213de555ac0470a87a7163e06c1f6c19c0ffb3b Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c7eedb39844a0131bbd86109a325f402bfa8bf2d&tochange=5213de555ac0470a87a7163e06c1f6c19c0ffb3b This is the same regression as in bug 1280337 comment 7.
Thanks for the regression range! Looks like Andreas may know more here but his bugzilla name says he's away until August 1. Paul reviewed the change in bug 1248154 so maybe he has thoughts here?
Component: DOM → Audio/Video: Playback
(Oops, see comment 6)
I will take a look at this. The fix in the patch took advantage of the fact that the received frame will actually set the width and height regardless of the initial setting. Perhaps there is a side effect where a 0 x 0 size will fail to generate a video tag in the DOM.
status-firefox47: --- → unaffected
status-firefox48: --- → affected
status-firefox49: --- → affected
status-firefox50: --- → affected
status-firefox48: affected → wontfix
I'm going to mark this as P1 because it is a regression.
Priority: -- → P1
Please see bug 1280337 comment 18, 22 and 25 (where it got resolved as INVALID). We were correcting a non-spec behavior for loadedmetadata, and SFU/MCU implementations that negotiate video (but don't use it or send a frame) cause video elements to a) play the audio (and update the time), but b) don't fire loadedmetadata because we don't know hte video dimensions (which had previously been reported on a number of occasions when we did fire it immediately). Chrome has a similar-but-not-identical issue where in this case they don't play audio *or* video until they can fire loadedmetadata. This is overall an unfortunate hole in the spec when used with non-transport streams, as it was designed with streaming media in mind.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1280337
Bug 1280337 is marked as invalid due to work as expected. So, mark 49/50 as won't fix.
status-firefox49: affected → wontfix
status-firefox50: affected → wontfix
You need to log in before you can comment on or make changes to this bug.