Chromium and XPCOM event queues are now unified

2016-05-12 Thread Kyle Huey
On inbound (and soon central), for Chromium MessageLoops that belong to an XPCOM thread (either the main thread, or created via the thread manager) posting tasks now calls through to the underlying XPCOM thread's dispatch implementation. This could cause subtle breakage because event ordering has

Re: Intent to deprecate: getUserMedia(cam+mic) to become all-or-nothing

2016-05-12 Thread Mike Taylor
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 right when the track is missing. Fixing sites sounds good. Are

Re: Intent to deprecate: getUserMedia(cam+mic) to become all-or-nothing

2016-05-12 Thread Jan-Ivar Bruaroey
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

Re: Updating 32-bit Windows users to 64-bit Windows builds?

2016-05-12 Thread khagaroth
On Thursday, May 12, 2016 at 11:47:15 PM UTC+2, Karl Tomlinson wrote: > Lawrence Mandel writes: > > > Do we need this criteria? > > > > RAM - Does it hurt to move an instance that has <4GB? > > Yes. OOM will be more common with 64-bit builds on systems with > less RAM because 64-bit builds use

Re: Updating 32-bit Windows users to 64-bit Windows builds?

2016-05-12 Thread L. David Baron
On Thursday 2016-05-12 15:33 -0700, Kyle Huey wrote: > On Thu, May 12, 2016 at 2:46 PM, Karl Tomlinson wrote: > > > Lawrence Mandel writes: > > > > > Do we need this criteria? > > > > > > RAM - Does it hurt to move an instance that has <4GB? > > > > Yes. OOM will be more

Re: Updating 32-bit Windows users to 64-bit Windows builds?

2016-05-12 Thread Kyle Huey
On Thu, May 12, 2016 at 2:46 PM, Karl Tomlinson wrote: > Lawrence Mandel writes: > > > Do we need this criteria? > > > > RAM - Does it hurt to move an instance that has <4GB? > > Yes. OOM will be more common with 64-bit builds on systems with > less RAM because 64-bit builds

Re: Updating 32-bit Windows users to 64-bit Windows builds?

2016-05-12 Thread Eric Rahm
Last time I checked we saw something like a 35% increase in overhead on AWSY going from 32-bit to 64-bit Firefox on 64-bit Windows, so yes there is a significant impact. On the other hand you no-longer run into the OOM-because-of-address-space-exhaustion and

Re: Updating 32-bit Windows users to 64-bit Windows builds?

2016-05-12 Thread Karl Tomlinson
Lawrence Mandel writes: > Do we need this criteria? > > RAM - Does it hurt to move an instance that has <4GB? Yes. OOM will be more common with 64-bit builds on systems with less RAM because 64-bit builds use more memory. ___ dev-platform mailing list

Re: Intent to deprecate: getUserMedia(cam+mic) to become all-or-nothing

2016-05-12 Thread Jonas Sicking
On Thu, May 12, 2016 at 12: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 right when the track is

Re: Updating 32-bit Windows users to 64-bit Windows builds?

2016-05-12 Thread Chris Peterson
Yes. Flash and Silverlight both have 64-bit plugins that work in 64-bit Firefox. Streaming video services will likely move their Firefox users from Silverlight to Widevine this year, so Silverlight usage will decline by EOY. On 5/12/16 1:10 PM, Ryan VanderMeulen wrote: Flash installs the

Re: Updating 32-bit Windows users to 64-bit Windows builds?

2016-05-12 Thread Ryan VanderMeulen
Flash installs the 32-bit and 64-bit plugin versions side by side already (in System32 and SysWOW64, respectively), so I don't think that's an issue here. -Ryan On 5/12/2016 3:38 PM, Lawrence Mandel wrote: Do we need this criteria? RAM - Does it hurt to move an instance that has <4GB? NPAPI

Intent to deprecate: getUserMedia(cam+mic) to become all-or-nothing

2016-05-12 Thread Jan-Ivar Bruaroey
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

Re: Updating 32-bit Windows users to 64-bit Windows builds?

2016-05-12 Thread Lawrence Mandel
Do we need this criteria? RAM - Does it hurt to move an instance that has <4GB? NPAPI - We've announced that we'll remove support this year [1]. Should we just wait until we do? Do we have a solution for Flash on Win64 that makes this viable? Lawrence [1]

Re: Updating 32-bit Windows users to 64-bit Windows builds?

2016-05-12 Thread Ben Hearsum
This is a slight change from the current model where we purposely make the client very dumb, and make the decision on the server (to minimize the possibility of client-side bug making updates impossible). However, this doesn't seem like a case where we could get somebody stuck very easily, and

Re: Updating 32-bit Windows users to 64-bit Windows builds?

2016-05-12 Thread Ted Mielczarek
I suspect we'd want to add some extra token like "it's ok to update this 32-bit build to a 64-bit build", and have all the gating logic live on the client-side. Odds are if we want to change the criteria we'd have to change the client anyway. -Ted On Thu, May 12, 2016, at 12:56 PM, Ben Hearsum

Re: Updating 32-bit Windows users to 64-bit Windows builds?

2016-05-12 Thread Ben Hearsum
Do you have thoughts on how we'll be able to serve the users the correct build if we have to base the decision on plugins they may have or other information that's not in the update ping? We can already detect 32-bit builds on 64-bit Windows through the build target, but information about

Re: Updating 32-bit Windows users to 64-bit Windows builds?

2016-05-12 Thread L. David Baron
On Thursday 2016-05-12 11:45 -0400, Ted Mielczarek wrote: > requirement for x86-64 processors, and the overall performance should > generally be better (modulo memory usage, I'm not sure if we have an > exact comparison). Additionally 64-bit builds are much less likely to > encounter OOM crashes

Re: Updating 32-bit Windows users to 64-bit Windows builds?

2016-05-12 Thread Aaron Klotz
The DLL Interceptor has some problems on 64-bit Windows 10 that we'd probably want to fix before doing this. See bug 1240977. On 5/12/2016 9:45 AM, Ted Mielczarek wrote: Hello, Given all the discussion around SSE[2] lately, I was curious as to whether we had made any plans to update Windows

Re: Updating 32-bit Windows users to 64-bit Windows builds?

2016-05-12 Thread Robert Strong
We would have to since other users on the system can have shortcuts pointing to the original location. We've also performed some minimal testing that this is fine when we looked into this a couple of years ago. Robert On Thu, May 12, 2016 at 8:53 AM, Ryan VanderMeulen wrote:

Updating 32-bit Windows users to 64-bit Windows builds?

2016-05-12 Thread Ted Mielczarek
Hello, Given all the discussion around SSE[2] lately, I was curious as to whether we had made any plans to update Windows users that are running 32-bit Windows builds on a 64-bit Windows OS to our 64-bit Windows builds. The 64-bit Windows builds do use SSE2, since that's a baseline requirement

Re: Two talos jobs for PGO builds on fx-team and m-i

2016-05-12 Thread Armen Zambrano G.
My apologies. I looked at the "default" value rather than the project specific cadence. https://dxr.mozilla.org/build-central/source/buildbot-configs/mozilla/project_branches.py#20 On 2016-05-12 11:12 AM, Ryan VanderMeulen wrote: On 5/12/2016 10:51 AM, Armen Zambrano G. wrote: IIUC, we have

Re: Two talos jobs for PGO builds on fx-team and m-i

2016-05-12 Thread Ryan VanderMeulen
On 5/12/2016 10:51 AM, Armen Zambrano G. wrote: IIUC, we have PGO builds running on fx-team and m-i every 6 hours. This only affects Linux x64 and Windows (not Mac). The test pools are shared between all repositories. This entails 14 extra jobs for Windows XP and Windows 8. This entails 16

Re: Two talos jobs for PGO builds on fx-team and m-i

2016-05-12 Thread Armen Zambrano G.
IIUC, we have PGO builds running on fx-team and m-i every 6 hours. This only affects Linux x64 and Windows (not Mac). The test pools are shared between all repositories. This entails 14 extra jobs for Windows XP and Windows 8. This entails 16 extra jobs for Windows 7. This is equivalent to two

Re: Two talos jobs for PGO builds on fx-team and m-i

2016-05-12 Thread Gregory Szorc
What impact will this have on machine capacity? The Windows and Mac testers are already highly overwhelmed. Try jobs are often delayed by several hours, which I think is a major concern. (I can't remember if we have a separate pool for Talos testers [on Try].) > On May 12, 2016, at 05:01,

Two talos jobs for PGO builds on fx-team and m-i

2016-05-12 Thread Armen Zambrano G.
Hello team, We're now scheduling two talos jobs for every PGO build on fx-team [1] and m-i. This is to help reduce the time it takes to find PGO specific regressions for these two branches. If you see any issues falling out of this please file it under Testing::General and CC me. This is

Re: Intent to deprecate: MacOS 10.6-10.8 support

2016-05-12 Thread sfbay . mapfixer
On Tuesday, May 10, 2016 at 8:07:05 PM UTC-7, Mike Hommey wrote: > On Tue, May 10, 2016 at 10:58:25PM -0400, Lawrence Mandel wrote: > > On Fri, May 6, 2016 at 6:43 AM, Xidorn Quan wrote: > > > > > On Fri, May 6, 2016 at 8:24 PM, Mike Hommey wrote: > > > > > > > On Fri, May 06, 2016 at