On 6/6/18 11:48 AM, Mark Côté wrote:
On Wednesday, 6 June 2018 11:18:43 UTC-4, Boris Zbarsky wrote:
* Stacked revisions. If you have a stack of revisions, that is, two or more
revisions with parent-child relationships, Lando cannot land them all at once.
Does Differential support this case n
On 6/6/18 1:49 PM, Boris Zbarsky wrote:
On 6/6/18 1:41 PM, Jan-Ivar Bruaroey wrote:
I think bz is asking about mozReview's ability to handle multiple
commits in a single review (and handle updates in both dimensions).
This fits the hg evolve model well, and was AFAIK a unique workfl
On 6/6/18 3:03 PM, Boris Zbarsky wrote:
On 6/6/18 2:52 PM, Jan-Ivar Bruaroey wrote:
Mozreview will show me the equivalent of "diff -r B -r P1", "diff -r P1
-r P2" and "diff -r P2 -r P3". If there are then edits to P1 to produce
Q1, the diff revision slider will
On 7/29/18 10:39 PM, Chris Pearce wrote:
Summary: HTMLMediaElement.allowedToPlay allows web authors to determine in
advance of calling HTMLMediaElement.play() whether the HTMLMediaElement in its
current state would be allowed to play, or would be blocked by the browser's
autoplay blocking poli
On 8/1/18 3:36 AM, Chris Pearce wrote:
On Tuesday, July 31, 2018 at 9:05:03 AM UTC+12, Jan-Ivar Bruaroey wrote:
On 7/29/18 10:39 PM, Chris Pearce wrote:
Summary: HTMLMediaElement.allowedToPlay allows web authors to determine in
advance of calling HTMLMediaElement.play() whether the
We're removing the isRemote member of the RTCRTPStreamStats [1]
dictionary used to identify remote statistics returned from the
peerConnection.getStats() method in WebRTC. [2]
The spec changed in 2017 to explicit types instead of this boolean. [3]
We just landed a deprecation warning in Nightl
On 8/6/18 4:03 PM, Jan-Ivar Bruaroey wrote:
On 8/1/18 3:36 AM, Chris Pearce wrote:
I think the only thing that you're missing is how vehemently some
sites are in their desire to avoid the doorhanger prompt.
No, I'm also missing why we should listen to them.
If Netflix fights our
On 1/26/16 10:56 PM, Karl Tomlinson wrote:
On Fri, 22 Jan 2016 14:24:38 -0500, Ehsan Akhgari wrote:
What about the case where the information doesn't exist in the
repository because the author, for example, cherry-picked a
specific commit on a throw-away branch because the rest of the
dependenc
Hi, this is an "intent to align with the spec" PSA.
The MediaCapture and Streams spec [1] says that sites requesting both
camera and microphone at the same time, must get both or nothing (in the
form of an error).
Firefox's permission doorhanger violates this invariant by offering
users the
On 5/12/16 4:41 PM, Jonas Sicking wrote:
This part should be fixable by creating a video stream which just
contains black (or a "anonymous user" icon or some such).
In theory yes, but I don't think the existing UX is salvageable when
mapped to mute (nowhere to unmute, and site now thinks it ha
On 5/12/16 7:26 PM, Mike Taylor wrote:
On 5/12/16 2:48 PM, Jan-Ivar Bruaroey wrote:
Our original intent behind those choices was to let users join a video
conference as an "audio only" participant. Unfortunately, sites don't
expect this behavior and often don't work rig
Data channels are modeled on web sockets, and I see we do this for web
sockets. https://bugzil.la/692067
However, data channels are typically opened to other *clients*, not servers.
What would the ContentLocation URI be in this case? The (dynamic) IP
used to reach the other client?
This seem
Summary:
Let developers read back what constraints have been put on
MediaStreamTracks by navigator.mediaDevices.getUserMedia() or
track.applyConstraints(), as well as the resulting net settings. The new
methods for this are track.getConstraints() and track.getSettings()
respectively. The sett
I support putting .revoke() behind a pref (I would like to go further
and remove it since I find it problematic, but a pref is a start).
On 8/17/16 3:34 AM, Anne van Kesteren wrote:
On Wed, Aug 17, 2016 at 9:13 AM, Marcos Caceres wrote:
We should maybe also pref .query() too... wdyt?
The ma
At the risk of sounding pragmatic/opportunistic, why not wait until the
usage numbers go down, as they're bound to?
.: Jan-Ivar :.
On 10/25/16 7:10 PM, Karl Dubost wrote:
Interesting thread. Going back to the starting email:
Le 22 oct. 2016 à 04:49, Richard Barnes a écrit :
Around 21% of th
On 4/10/15 2:09 PM, Seth Fowler wrote:
On Apr 10, 2015, at 8:46 AM, Ehsan Akhgari wrote:
I would like to propose that we should ban the usage of refcounted objects
inside lambdas in Gecko. Here is the reason:
Consider the following code:
nsINode* myNode;
TakeLambda([&]() {
myNode->Foo();
}
On 4/13/15 1:36 PM, Jan-Ivar Bruaroey wrote:
[2]
http://mxr.mozilla.org/mozilla-central/source/xpco/glue/nsThreadUtils.cpp?mark=164-168#164
working link I hope:
http://mxr.mozilla.org/mozilla-central/source/xpcom/glue/nsThreadUtils.cpp?mark=164-168#164
On 4/10/15 4:26 PM, smaug wrote:
I'd say that is rather painful for reviewers, since both Move() (I
prefer .swap()) and lambda hide what is actually happening to the refcnt.
Wanna ban copy construction? ;)
Higher-level constructs inherently "hide" something, but I disagree they
make things ha
On 4/14/15 10:06 AM, Ehsan Akhgari wrote:
On 2015-04-13 1:36 PM, Jan-Ivar Bruaroey wrote:
The above is a raw pointer bug, not a lambda bug.
Yes, I'm aware. Please see bug 1114683.
Thanks, I was not aware of this larger effort. This somewhat addresses
my concern that we seem overly fo
On 4/14/15 5:39 PM, Randell Jesup wrote:
I wonder if we could move to requiring already_AddRefed for
DispatchToMainThread (and Dispatch?), and thus block all attempts to do
DispatchToMainThread(new FooRunnable), etc. :-)
Yes! +1.
I like the .forget() semantics, but just to have options, here'
On 5/14/15 4:22 PM, Gijs Kruitbosch wrote:
On 14/05/2015 19:08, Martin Thomson wrote:
If you intend to support false and null and undefined and NaN and
attribute the same semantics, _say so_. Make it explicit. Don't make
me (the person reading your code years later) that this is your
intent.
On 6/2/15 6:28 PM, Boris Zbarsky wrote:
On 6/2/15 6:12 PM, Seth Fowler wrote:
If you write this:
auto val = Bar();
Foo(val);
I think to preserve the semantics of Foo(Bar()) you need:
auto& val = Bar();
Foo(val);
but apart from that nit, I totally agree.
This. Allow auto or lift the
Hi,
We intend to un-prefix HTMLMediaElement.srcObject (it currently exists
as HTMLMediaElement.mozSrcObject), even though it only supports a subset
of the types mandated in the spec. [1]
This means it will support get/set of: MediaStream objects.
This means it will throw TypeError on set of:
On 7/15/15 9:28 PM, jyaven...@mozilla.com wrote:
I need to complete bug 886194 then (that add MSE supports).
Yes, or at least rename the subject slightly. ;)
PS: We have the same first name in different language. awesome.
Hey, that's rare for us!
.: Jan-Ivar :.
___
On 7/15/15 11:50 PM, Boris Zbarsky wrote:
On 7/15/15 3:42 PM, Jan-Ivar Bruaroey wrote:
This means it will support get/set of: MediaStream objects.
This means it will throw TypeError on set of: MediaSource objects, Blob
objects, and File objects, for now.
Jan-Ivar,
Do you happen to know
On 8/8/18 12:53 PM, Boris Zbarsky wrote:
On 8/8/18 12:43 PM, Chris Pearce wrote:
On Tuesday, August 7, 2018 at 7:51:50 PM UTC-7, Jan-Ivar Bruaroey wrote:
To clarify, I care about Netflix, which is why I question giving up on
persisting autoplay for them, which is what allowedToPlay does.
So
On 8/8/18 12:43 PM, Chris Pearce wrote:
Hi Jib,
I appreciate that you care passionately about our users' best interests.
Seeing as you asked "why don't you just?"... Here's why we "didn't just"...
On Tuesday, August 7, 2018 at 7:51:50 PM UTC-7, Jan-Ivar
Summary: Firefox has long supported screen capture through a proprietary
non-standard extension of getUserMedia(). We intend to implement the
standard getDisplayMedia() API, and eventually remove the old
non-standard API. This exposes existing functionality in a standard way.
Bug: https://bugz
TL;DR: anticipate very low impact.
We don't have telemetry for these, but we've been warning about these in
web console since 55. [1]
These are legacy names for the standard autoGainControl and
noiseSuppression constraints we've supported since 55. [1]
You can try it out here
https://blog.
On 10/10/18 4:29 PM, Mike Taylor wrote:
Hi Jan-Ivar,
On 10/10/18 9:48 AM, Jan-Ivar Bruaroey wrote:
The most likely net fallout of, if any, would be sites that UA-sniff
AND rely on the legacy Firefox names ONLY to turn OFF audio
processing. These are likely to be specialty sites dealing with
TL;DR: the getUserMedia API will reject with NotAllowedError in insecure
contexts in Firefox 67 (due mid-May), and we'll experiment with
navigator.mediaDevices being [SecureContext] in Nightly going forward.
Hi! We're moving to restrict the getUserMedia and enumerateDevices APIs,
in two stages
"Perfect Negotiation" refers to four API improvements to WebRTC that
together make signaling non-racy and more ergonomic. They are (with FF
target and bug #):
1. 70 http://bugzil.la/1551316 restartIce()
2. 70 http://bugzil.la/1567951 setRemoteDescription() with "rollback"
3. 70 http://bugzil.la
nce the new APIs are all done. I hope to
write a follow-up blog once we can demo the new APIs.
Cheers!
.: Jan-Ivar :.
On 7/23/19 9:10 PM, Jan-Ivar Bruaroey wrote:
"Perfect Negotiation" refers to four API improvements to WebRTC that
together make signaling non-racy and more ergonomic.
This always seemed trivial to me to do with:
Promise.all(promises.map(p => p.catch(e => e)))
https://stackoverflow.com/questions/31424561/wait-until-all-promises-complete-even-if-some-rejected/36115549#36115549
But I guess it's too late to make that point. I guess the more
primitives the m
ually had an opportunity to use this pattern
for anything...
.: Jan-Ivar :.
On 10/30/19 6:39 PM, Boris Zbarsky wrote:
On 10/30/19 6:19 PM, Jan-Ivar Bruaroey wrote:
This always seemed trivial to me to do with:
Promise.all(promises.map(p => p.catch(e => e)))
This has different sem
Promise.any is an inverse of Promise.all, right? There and back again:
Promise.all(promises.map(p => p.then(r => Promise.reject(r), e => e)))
.then(r => Promise.reject(r), e => e)
https://jsfiddle.net/jib1/f085bcyk/
That said, Promise.any has a nice ring to it.
.: Jan-Ivar :.
On 10/30/19 6:
On 10/31/19 4:26 AM, Paolo Amadini wrote:
On 10/30/2019 10:19 PM, Jan-Ivar Bruaroey wrote:
Promise.all(promises.map(p => p.catch(e => e)))
https://stackoverflow.com/questions/31424561/wait-until-all-promises-complete-even-if-some-rejected/36115549#36115549
By the way, this &q
On 11/1/19 6:08 AM, Paolo Amadini wrote:
On 10/31/2019 1:57 PM, Jan-Ivar Bruaroey wrote:
The context here is the same as Promise.allSettled: we explicitly *do*
want to ignore errors, right?
In general, in mozilla-central we want to at least log those errors, at
which point they are already
38 matches
Mail list logo
