calling MediaStreamTrack.stop() fires ended event on track |
||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/59.0.3071.109 Chrome/59.0.3071.109 Safari/537.36 Steps to reproduce the problem: 1. go to https://jsfiddle.net/5o36pyjn/ 2. run the fiddle What is the expected behavior? no console.log What went wrong? the ended event is fired on the track. Events should not fire as a result of calling .stop() Did this work before? N/A Does this work in other browsers? Yes Chrome version: 59.0.3071.109 Channel: n/a OS Version: Flash Version: Shockwave Flash 16.0 r0 When a MediaStreamTrack track ends for any reason other than the stop() method being invoked, the User Agent must queue a task that runs the following steps: [...] Fire a simple event named ended at the object.
,
Aug 16 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0f5fe0838638b0efc207b1945f9e427d58060aff commit 0f5fe0838638b0efc207b1945f9e427d58060aff Author: Guido Urdaneta <guidou@chromium.org> Date: Wed Aug 16 15:16:31 2017 Do not fire ended event on MediaStreamTrack.stop() The spec says the ended event must be fired when "a track ends for any reason other than the stop() method being invoked". Drive-by: Migrate affected tests to testharness. Bug: 752913 Change-Id: I206907a6d14b9e249e611c056cff46388c03b186 Reviewed-on: https://chromium-review.googlesource.com/612286 Reviewed-by: Philip Jägenstedt <foolip@chromium.org> Commit-Queue: Guido Urdaneta <guidou@chromium.org> Cr-Commit-Position: refs/heads/master@{#494789} [modify] https://crrev.com/0f5fe0838638b0efc207b1945f9e427d58060aff/third_party/WebKit/LayoutTests/external/wpt/mediacapture-streams/MediaStream-idl.https.html [delete] https://crrev.com/09503699783ba50bb017f498dbc7972f20744623/third_party/WebKit/LayoutTests/fast/mediastream/MediaStreamTrack-expected.txt [delete] https://crrev.com/09503699783ba50bb017f498dbc7972f20744623/third_party/WebKit/LayoutTests/fast/mediastream/MediaStreamTrack-observer-iterate-no-crash-expected.txt [modify] https://crrev.com/0f5fe0838638b0efc207b1945f9e427d58060aff/third_party/WebKit/LayoutTests/fast/mediastream/MediaStreamTrack-observer-iterate-no-crash.html [modify] https://crrev.com/0f5fe0838638b0efc207b1945f9e427d58060aff/third_party/WebKit/LayoutTests/fast/mediastream/MediaStreamTrack.html [modify] https://crrev.com/0f5fe0838638b0efc207b1945f9e427d58060aff/third_party/WebKit/Source/modules/mediastream/MediaStreamTrack.cpp
,
Sep 14 2017
,
Sep 21 2017
How can we be notified that the track has been ended now? we stop the track and want to do something else while receiving the "ended" event before.
,
Sep 21 2017
Seconding comment 4... any idea of the rationale here? Why does the spec say this?
,
Sep 21 2017
The proper place to answer #5 would be to file a spec bug at https://github.com/w3c/mediacapture-main/issues andrew@: Can you file that bug? FWIW, in the old Chrome implementation the event was fired right after stop() was invoked. There was no wait for lower-layer implementations to produce a callback or anything like that. This means that you can easily reproduce similar behavior in JavaScript by firing a task right after calling stop().
,
Sep 21 2017
the rationale is that in general if you request an action like stop() you won't get the ended. As Guido said, move the stuff you are doing in onended to where you call stop. This frees up onended for things like devices being unplugged. |
||
►
Sign in to add a comment |
||
Comment 1 by guidou@chromium.org
, Aug 9 2017Status: Assigned (was: Unconfirmed)