Re: Sort out active state spec inconsistencies

Den 01. des. 2015 11:03, skrev Adam Bergkvist:
> Anyone else that has input on this matter?
> 
> Otherwise, I'll go ahead and create an github issue.

I'm fine with creating an issue and suggesting #3 as the resolution.

> 
> /Adam
> 
> On 2015-11-24 09:34, Adam Bergkvist wrote:
>> I wouldn't mind going down the path of #3 since it would indeed simplify
>> things to get rid of the double events. I wonder how much code we would
>> break (besides browser layout tests).
>>
>> /Adam
>>
>> On 2015-11-23 23:18, Peter Thatcher wrote:
>>> I like #3.  It simplifies.  The JS can get to the information it needs
>>> and doesn't need it to be duplicated in a complex way.
>>>
>>> On Tue, Nov 17, 2015 at 2:18 AM, Adam Bergkvist
>>> <adam.bergkvist@ericsson.com <mailto:adam.bergkvist@ericsson.com>> wrote:
>>>
>>>      Hi
>>>
>>>      We have some inconsistencies in the spec regarding the active state.
>>>
>>>      We define active in terms of the stream's track set. In short, if a
>>>      non-ended track exists, the stream is active, otherwise inactive.
>>>
>>>      The active attribute is specified to return true if the stream is active
>>>      and false otherwise.
>>>
>>>      We also specify that when a stream goes from active, to inactive, the
>>>      active attribute should be updated to true and the event fired. This
>>>      contradicts the other text that defines the attribute in terms of the
>>>      stream's track set.
>>>
>>>      Possible solutions:
>>>
>>>      1. Just remove the attribute updating part of the event dispatching
>>>      steps.
>>>
>>>      Since the events are scheduled and fired as a result of sync API calls,
>>>      we might en up in a situation that an "active" event is fired, but
>>>      that's not true (anymore).
>>>
>>>      2. Remove the attribute updating part of the event dispatching and use a
>>>      activitychanged event instead of specific active/inactive events.
>>>
>>>      This way when a scheduled event fires, the script needs to check the
>>>      attribute manually and react. We never get the "event type" - "attribute
>>>      value" mismatch.
>>>
>>>      3. Remove the active/inactive events all together.
>>>
>>>      These events are rather unnecessary. They either follow direct
>>>      manipulation from the script or some other event when the UA has
>>>      initiated a the result of a change to a stream's track set. For example
>>>      the add/removetrack events or MediaStreamTrack ended.
>>>
>>>      /Adam
>>>
>>>
>>
>>
>>
> 
>

Received on Tuesday, 1 December 2015 14:13:29 UTC