Hey all,
Thanks for the replies. I'm mostly confused about how intently we need
this. What applications does this improve? How?
Seeing a block of before/after example code that shows the problem in situ
is usually how we get a minimal sense of how this will play out for
customers. Not having that, and being asked to ship this first, raises the
risk, particularly absent customers/developers telling us how this is going
to make lives better.
Best,
Alex
On Wednesday, February 4, 2026 at 4:41:30 AM UTC-8 PhistucK wrote:
> > But you're saying that I have no way of knowing up front if it's one or
> the other.
> I think there is, but it is not pretty - calling
> peerConnection.createOffer() will generate that SDP message and you can
> parse it a bit to see if the data channel (m=application) shows up first
> - that means the boolean worked.
> Of course, parsing the SDP is a pretty big hammer just for knowing whether
> the boolean is supported...
> Looks like new RTCPeerConnection({alwaysNegotiateDataChannels: true})
> does not fail to create a peer connection at the moment, so unsupported
> constraints cannot easily be feature-tested.
> Perhaps using a getter rather than a simple true ({get
> alwaysNegotiateDataChannels()
> { isConstraintSupported = true; return true; }}) would also work.
>
>
> ☆*PhistucK*
>
>
> On Wed, Feb 4, 2026 at 4:20 AM Yoav Weiss (@Shopify) <
> [email protected]> wrote:
>
>> A potentially silly question, due to my complete ignorance of WebRTC
>> protocol negotiations:
>> If I'm planning to use this new boolean, that means that I may or may not
>> want to negotiate a data channel.
>> If the other side doesn't support the boolean, I need to create a dummy
>> data channel. If it does, I don't need to create one.
>> But you're saying that I have no way of knowing up front if it's one or
>> the other.
>>
>> So how would developers know if they need to create a dummy channel? Is
>> there some response to this boolean that indicates support or lack-thereof?
>> If so, presumably it's not too late to create the dummy channel at that
>> point?
>>
>>
>>
>> On Tuesday, February 3, 2026 at 1:57:19 PM UTC+1
>> [email protected] wrote:
>>
>>> Alex,
>>>
>>> this boils down to WebRTCs notion that the "SDP" is a " blob". Which
>>> makes the API look easy but from the amount of fighting over the plan-b
>>> deprecation, "sdp munging" or even the question when inbound-rtp stats
>>> appear, this is causing trouble since this "blob" controls a ton of
>>> behavior.
>>>
>>> Developers can parse the SDP, e.g. like
>>> https://jsfiddle.net/fippo/kct3dy46/
>>> which with the new option set should return ["application", "video"]
>>> instead of ["video", "application"].
>>>
>>> The opt-in boolean avoids changing the default behavior so no surprises
>>> unless you use it.
>>> If you opt in you also (implicitly) agree that you are ready to deal
>>> with the feature not being supported.
>>> So the other end that is parsing and processing the SDP you generate is
>>> today receiving
>>> audio-video-data
>>> without the opt-in and you ensure it works with
>>> data-audio-video
>>> but you will still need to support the old way.
>>> I am not worried about browsers where we deal with only two SDP parsers
>>> and both are well written robust enough to deal with.
>>>
>>> cheers
>>>
>>> Philipp
>>>
>>>
>>> Am Mo., 2. Feb. 2026 um 21:04 Uhr schrieb Alex Russell <
>>> [email protected]>:
>>>
>>>> It's a little concerning that there's no explainer and no (reasonable?)
>>>> example code. How can developers debug that they're getting the intended
>>>> behaviour? Will they be surprised by the change(s) and/or across browsers?
>>>>
>>>> Best,
>>>>
>>>> Alex
>>>>
>>>> On Friday, January 30, 2026 at 2:16:03 AM UTC-8
>>>> [email protected] wrote:
>>>>
>>>>> Am Di., 27. Jan. 2026 um 09:27 Uhr schrieb Henrik Boström <
>>>>> [email protected]>:
>>>>>
>>>>>> This feature is only needed by the endpoint that creates the initial
>>>>>> offer and decides the m= section order, i.e. the other endpoint -
>>>>>> whether
>>>>>> they support this feature or not - will accept the m= section order that
>>>>>> is
>>>>>> on offer. Once the order is decided, it is "locked in" by both
>>>>>> endpoints,
>>>>>> as per old SDP rules. So it should be cross-browser compatible and
>>>>>> backwards-compatible, here's me setting SDP with m= application line
>>>>>> first
>>>>>> and the offer is accepted: https://jsfiddle.net/henbos/oweu42yz/
>>>>>>
>>>>>> As for if the browser that is creating this offer supports the
>>>>>> feature, you can feature detect by testing it on a throwaway
>>>>>> RTCPeerConnection object that you immediately close afterwards.
>>>>>>
>>>>>
>>>>> Throwaway peerconnections are an antipattern too ;-)
>>>>> Since RTCConfiguration is not exposed on window one can not feature
>>>>> detect upfront but one can call pc.getConfiguration() to see if this had
>>>>> an
>>>>> effect after creating the connection and then adapt if necessary (i.e.
>>>>> create the not-quite-throwaway channel)
>>>>> Not sure I would bother with feature detection, the other side should
>>>>> support the resulting SDP both with the new behavior of datachannels
>>>>> being
>>>>> first or the current behavior so opt-in should be fine with fallback to
>>>>> the
>>>>> current status quo.
>>>>>
>>>>>
>>>>>> On Monday, January 26, 2026 at 4:46:05 PM UTC+1 Robert Flack wrote:
>>>>>>
>>>>>>> On Mon, Jan 26, 2026 at 10:25 AM Robert Flack <[email protected]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Sorry, quick followup, keeping always in the name would make sense
>>>>>>>> if it was explained that because this is negotiated first it ensures
>>>>>>>> that
>>>>>>>> we at least will always negotiate a data channel even if audio and
>>>>>>>> video
>>>>>>>> fail.
>>>>>>>>
>>>>>>>> On Mon, Jan 26, 2026 at 10:23 AM Robert Flack <[email protected]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Thank you for the explanation. I definitely agree that this sounds
>>>>>>>>> very important. My concern remains that the parameter name and
>>>>>>>>> developer documentation does not convey this and without this context
>>>>>>>>> it's
>>>>>>>>> unclear why I should use this. As an example, the config parameter
>>>>>>>>> could
>>>>>>>>> just be called negotiateDataChannels, as a cue that this will ensure
>>>>>>>>> your
>>>>>>>>> connection is configured to support creating data channels. It would
>>>>>>>>> be
>>>>>>>>> worth also explaining why you want to do this, with a short snippet
>>>>>>>>> showing
>>>>>>>>> how a data channel can be added later.
>>>>>>>>>
>>>>>>>>
>>>>> Negotiating datachannels is already an overloaded term - the SDP
>>>>> negotiates support and datachannels themselves are negotiated in-band but
>>>>> can also be negotiated out-of-band.
>>>>>
>>>>>
>>>>>>>>> The spec says that it is negotiated before audio or video but
>>>>>>>>> doesn't explain why you might want to do this - i.e. to ensure that
>>>>>>>>> you can
>>>>>>>>> negotiate a connection even if the audio or video channels fail to
>>>>>>>>> negotiate a compatible codec.
>>>>>>>>>
>>>>>>>>> TLDR; I'm not opposed to this feature - after learning what it
>>>>>>>>> does and why, I agree we need it. I just think it would be very hard
>>>>>>>>> for
>>>>>>>>> someone reading about this to understand that they should use it to
>>>>>>>>> resolve
>>>>>>>>> these issues.
>>>>>>>>>
>>>>>>>>
>>>>> The WebRTC samples <https://github.com/webrtc/samples> have always
>>>>> been great for showing how a feature works but in this case even I have a
>>>>> hard time coming up with a good sample.
>>>>> Adoption is more likely from opensource projects currently working
>>>>> around this like MediaSoup and then it trickles down from there. Who
>>>>> knows,
>>>>> maybe Google Meet might drive adoption just to get rid of the "ignored"
>>>>> datachannel ;-)
>>>>>
>>>>> I have updated the description accordingly.
>>>>>
>>>>> cheers
>>>>>
>>>>> Philipp
>>>>>
>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Jan 26, 2026 at 7:31 AM Henrik Boström <[email protected]>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> This simple API plugs a missing piece of functionality: there is
>>>>>>>>>> no way to tell WebRTC that you may want to use data channels at some
>>>>>>>>>> point
>>>>>>>>>> in the future without having to re-negotiate, so the only way to
>>>>>>>>>> ensure you
>>>>>>>>>> negotiate data channels unconditionally is to create these dummy
>>>>>>>>>> data
>>>>>>>>>> channels not to be intended for use that you have to manually ignore
>>>>>>>>>> at the
>>>>>>>>>> other endpoint, both with regards to events firing and when parsing
>>>>>>>>>> statistics.
>>>>>>>>>>
>>>>>>>>>> Creating dummy data channels is a workaround to a mistake in the
>>>>>>>>>> API in my opinion, and I would support it even if all that it
>>>>>>>>>> achieved was
>>>>>>>>>> API ergonomics.
>>>>>>>>>>
>>>>>>>>>> But it does achieve something more than the workaround is able
>>>>>>>>>> to: placing the m= application line at the top. The fact that the
>>>>>>>>>> order of
>>>>>>>>>> m= sections is more predictable reduces the risk of application
>>>>>>>>>> bugs. I
>>>>>>>>>> believe Google Meet had a serious regression a few years ago where
>>>>>>>>>> the m=
>>>>>>>>>> section order was something not what we expected causing the SDP
>>>>>>>>>> parser to
>>>>>>>>>> fail and the call to be disconnected. It's also a good idea that the
>>>>>>>>>> m=
>>>>>>>>>> application line gets tagged, avoiding risk of rejecting the whole
>>>>>>>>>> bundle
>>>>>>>>>> if the wrong m= section is rejected.
>>>>>>>>>> On Thursday, January 22, 2026 at 3:20:18 PM UTC+1 Philipp Hancke
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> bear with me while I try to explain 15 years of history...
>>>>>>>>>>>
>>>>>>>>>>> Am Mi., 21. Jan. 2026 um 16:39 Uhr schrieb Rick Byers <
>>>>>>>>>>> [email protected]>:
>>>>>>>>>>>
>>>>>>>>>>>> This is generally why we require explainers. Part of the point
>>>>>>>>>>>> of this launch process is ensuring we've got the public material
>>>>>>>>>>>> for web
>>>>>>>>>>>> developers to understand the feature. Harald can you post an
>>>>>>>>>>>> explainer
>>>>>>>>>>>> somewhere which includes answers to Rob's questions?
>>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Rick
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Jan 21, 2026 at 9:30 AM Robert Flack <
>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> The specification just says "alwaysNegotiateDataChannels
>>>>>>>>>>>>> defines a way for the application to negotiate data channels in
>>>>>>>>>>>>> the SDP
>>>>>>>>>>>>> offer before creating a datachannel".
>>>>>>>>>>>>>
>>>>>>>>>>>> I'm finding it a bit hard to reason about what this means for
>>>>>>>>>>>>> me as a developer. I.e. when should I set it and how does this
>>>>>>>>>>>>> change the
>>>>>>>>>>>>> connection?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> Lets say you create a RTCPeerConnection. Create an offer and
>>>>>>>>>>> call setLocalDescription. Send it to your peer. You get an answer
>>>>>>>>>>> from the
>>>>>>>>>>> peer and feed it into setRemoteDescription.
>>>>>>>>>>> You might wonder why it does not result in a connection.
>>>>>>>>>>>
>>>>>>>>>>> Next, you create a datachannel. Your datachannel never opens
>>>>>>>>>>> because after adding the datachannel (only the first!) you need to
>>>>>>>>>>> call
>>>>>>>>>>> createOffer/setLocalDescription and call setRemoteDescription with
>>>>>>>>>>> the
>>>>>>>>>>> answer.
>>>>>>>>>>> "web developers" are notably confused:
>>>>>>>>>>>
>>>>>>>>>>> https://stackoverflow.com/questions/79737908/how-do-i-create-a-data-channel-in-webrtc-js-firefox-115-6-esr
>>>>>>>>>>> Now your connection gets established. If you add another data
>>>>>>>>>>> channel you do *not* need to do this negotiation again (thankfully;
>>>>>>>>>>> adding
>>>>>>>>>>> audio or video tracks requires negotiation).
>>>>>>>>>>>
>>>>>>>>>>> In this case using the boolean flag is saving you one round of
>>>>>>>>>>> negotiation.
>>>>>>>>>>>
>>>>>>>>>>> In many applications you do not know if you want to use a
>>>>>>>>>>> datachannel but since you might, you preemptively create one and
>>>>>>>>>>> throw it
>>>>>>>>>>> away. You can see that e.g. in Google Meet which calls
>>>>>>>>>>> pc.createDataChannel("ignored", {reliable: true})
>>>>>>>>>>> It never uses that channel but it shows up in the getStats API
>>>>>>>>>>> every time.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Does this mean that a data channel will be negotiated without
>>>>>>>>>>>>> calling createDataChannel?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> The underlying SCTP association will be negotiated and can be
>>>>>>>>>>> used by subsequent calls to createDataChannel without renegotiation.
>>>>>>>>>>> This currently means exchanging four packets over the network
>>>>>>>>>>> (but that upfront cost might go away later this year).
>>>>>>>>>>> Everything is set up to just work.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Will that requested datachannel result in a datachannel event
>>>>>>>>>>>>> or does my code still need to call createDataChannel? If the
>>>>>>>>>>>>> latter, is
>>>>>>>>>>>>> this a performance optimization?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> Part of it is a performance / ergonomics optimization. But
>>>>>>>>>>> behold, there comes the 2011 backward compat angle below.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Would I choose this when data is more important to connect
>>>>>>>>>>>>> first rather than e.g. voice / video?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> Lets say you have a stream from getUserMedia with audio and
>>>>>>>>>>> video and would also like to have a datachannel.
>>>>>>>>>>> You call pc.createDataChannel and then iterate over the
>>>>>>>>>>> MediaStream's getTracks and call pc.addTrack with each.
>>>>>>>>>>> Because data channels were new and fancy in 2011 and backward
>>>>>>>>>>> compat was a concern this results in SDP (due to rules in RFC 8829)
>>>>>>>>>>> which
>>>>>>>>>>> puts the datachannel bits in the SDP after the audio and video bits
>>>>>>>>>>> (and in
>>>>>>>>>>> Safari the order of audio and video bits depend on the lexical
>>>>>>>>>>> ordering of
>>>>>>>>>>> the random uuid of the MediaStreamTrack) so the SDP looks roughly
>>>>>>>>>>> like this:
>>>>>>>>>>> v=0 (6 more lines)
>>>>>>>>>>> m=audio 9 UDP/TLS/RTP/SAVPF 63 111 (23 more lines)
>>>>>>>>>>> direction=sendonly mid=0
>>>>>>>>>>> m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 45 46 (63 more
>>>>>>>>>>> lines) direction=sendonly mid=1
>>>>>>>>>>> m=application 9 UDP/DTLS/SCTP webrtc-datachannel (9 more
>>>>>>>>>>> lines) direction=sendrecv mid=2
>>>>>>>>>>>
>>>>>>>>>>> Which is ok but you are probably scratching your head why this
>>>>>>>>>>> order does not match the order of calls (or why in Safari you get
>>>>>>>>>>> video-audio-application half the time)
>>>>>>>>>>> https://www.rfc-editor.org/rfc/rfc8829.html#name-initial-offers
>>>>>>>>>>> specifies this (search for "Lastly, ") but does not provide much of
>>>>>>>>>>> a
>>>>>>>>>>> rationale. https://github.com/w3c/webrtc-pc/issues/735 has some
>>>>>>>>>>> 2016 rationale.
>>>>>>>>>>> Now that seems like an odd choice but had little consequence
>>>>>>>>>>> until...
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> The linked tracking bug
>>>>>>>>>>>>> <https://issues.chromium.org/433898678> appears to be a
>>>>>>>>>>>>> chrome-only bug report with a particular demo that doesn't use
>>>>>>>>>>>>> the
>>>>>>>>>>>>> alwaysNegotiateDataChannels attribute and works on Firefox. I
>>>>>>>>>>>>> don't quite
>>>>>>>>>>>>> understand what the new configuration extension has to do with
>>>>>>>>>>>>> the original
>>>>>>>>>>>>> bug report.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> WebRTC added APIs that allow you to negotiate codecs at some
>>>>>>>>>>> point. This can result in a situation where you end up with a
>>>>>>>>>>> incompatible
>>>>>>>>>>> set of video codecs (see the bug) and if those happen to be first
>>>>>>>>>>> in the
>>>>>>>>>>> SDP this "m=" line will be marked as "rejected" and can not be used
>>>>>>>>>>> to
>>>>>>>>>>> convey the transport information anymore.
>>>>>>>>>>> At best this results in another round of negotiation to satisfy
>>>>>>>>>>>
>>>>>>>>>>> https://datatracker.ietf.org/doc/html/rfc8843#name-rejecting-a-media-descripti
>>>>>>>>>>>
>>>>>>>>>>> Now
>>>>>>>>>>> https://datatracker.ietf.org/doc/html/rfc8843#section-7.2.1
>>>>>>>>>>> actually provides a recommendation on how to avoid this: you
>>>>>>>>>>> pick something that is "unlikely to be rejected by the remote side".
>>>>>>>>>>> The browser does not have an API that would lead to it rejecting
>>>>>>>>>>> a datachannel m= line (which can happen for audio and video)
>>>>>>>>>>> So it would be great to pick this datachannel m= line as
>>>>>>>>>>> "offerer tagged" which avoids this headache.
>>>>>>>>>>> But that requires (unless you want to risk more breakage)
>>>>>>>>>>> putting this m= line first which is conflicts with the rules of RFC
>>>>>>>>>>> 8829.
>>>>>>>>>>> The alternative is going through at least two rounds of
>>>>>>>>>>> negotiation (which involves the remote end), the first datachannel
>>>>>>>>>>> only and
>>>>>>>>>>> then adding media.
>>>>>>>>>>> Hence you need a way to opt-in which is the boolean in the
>>>>>>>>>>> RTCConfiguration.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>> It sounds like you're saying here that this may not be backwards
>>>>>>> compatible and if the other end doesn't support it you may not be able
>>>>>>> to
>>>>>>> establish a connection. If so, is it possible for the developer to
>>>>>>> feature
>>>>>>> detect whether the browser supports this so that they may determine
>>>>>>> whether
>>>>>>> both ends support this or not before setting it?
>>>>>>>
>>>>>>> Would you like to hear more about why WebRTC is so weird? (a lot of
>>>>>>>>>>> this boils down to "SDP is not an opaque blob)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Jan 21, 2026 at 6:31 AM 'Philipp Hancke' via blink-dev
>>>>>>>>>>>>> <[email protected]> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> *tContact emails*
>>>>>>>>>>>>>> [email protected], [email protected]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Specification*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://w3c.github.io/webrtc-extensions/#always-negotiating-datachannels
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Summary*
>>>>>>>>>>>>>> Implement
>>>>>>>>>>>>>> https://w3c.github.io/webrtc-extensions/#always-negotiating-datachannels
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Blink component*
>>>>>>>>>>>>>> Blink>WebRTC
>>>>>>>>>>>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EWebRTC%22>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Web Feature ID*
>>>>>>>>>>>>>> Missing feature
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *TAG review status*
>>>>>>>>>>>>>> Not applicable (incremental addition to WebRTC)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Risks*
>>>>>>>>>>>>>> *Interoperability and Compatibility*
>>>>>>>>>>>>>> *No information provided*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Gecko*: No signal (
>>>>>>>>>>>>>> https://github.com/mozilla/standards-positions/issues/1335)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *WebKit*: No signal (
>>>>>>>>>>>>>> https://github.com/WebKit/standards-positions/issues/599)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Web developers*: No signals
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Will this feature be supported on all six Blink platforms
>>>>>>>>>>>>>> (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?*
>>>>>>>>>>>>>> Yes
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Is this feature fully tested by web-platform-tests
>>>>>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?*
>>>>>>>>>>>>>> Yes, a WPT is part of
>>>>>>>>>>>>>> https://chromium-review.googlesource.com/c/chromium/src/+/7080041
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Rollout plan*
>>>>>>>>>>>>>> Will ship enabled for all users
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Requires code in //chrome?*
>>>>>>>>>>>>>> False
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Tracking bug*
>>>>>>>>>>>>>> https://issues.chromium.org/issues/433898678
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Estimated milestones*
>>>>>>>>>>>>>> Shipping on desktop 146
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Link to entry on the Chrome Platform Status*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://chromestatus.com/feature/5113419982307328?gate=6516338099093504
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This intent message was generated by Chrome Platform Status
>>>>>>>>>>>>>> <https://chromestatus.com/>.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> You received this message because you are subscribed to the
>>>>>>>>>>>>>> Google Groups "blink-dev" group.
>>>>>>>>>>>>>> To unsubscribe from this group and stop receiving emails from
>>>>>>>>>>>>>> it, send an email to [email protected].
>>>>>>>>>>>>>> To view this discussion visit
>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKiKuE79-xWUFiO9NCy%2Big9Pvn1oi6fVbkdomFLo4--bJQw%40mail.gmail.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKiKuE79-xWUFiO9NCy%2Big9Pvn1oi6fVbkdomFLo4--bJQw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> You received this message because you are subscribed to the
>>>>>>>>>>>>> Google Groups "blink-dev" group.
>>>>>>>>>>>>> To unsubscribe from this group and stop receiving emails from
>>>>>>>>>>>>> it, send an email to [email protected].
>>>>>>>>>>>>> To view this discussion visit
>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh39TPTxV5evdFUMnmfQE3aP2siNXNSZVpBr8wBitT56-nFCQ%40mail.gmail.com
>>>>>>>>>>>>>
>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh39TPTxV5evdFUMnmfQE3aP2siNXNSZVpBr8wBitT56-nFCQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>>>>>>>>>> .
>>>>>>>>>>>>>
>>>>>>>>>>>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>>
> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> To view this discussion visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/44ea71a3-1710-4b0f-97f7-6df551fbe7efn%40chromium.org
>>
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/44ea71a3-1710-4b0f-97f7-6df551fbe7efn%40chromium.org?utm_medium=email&utm_source=footer>
>> .
>>
>
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2ea27132-781b-46ef-834d-5de005128743n%40chromium.org.
