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
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
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
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
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
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
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
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
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
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
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
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
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]
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
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
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
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
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
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:
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
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
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
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
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,
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
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
26 matches
Mail list logo