Chromium and XPCOM event queues are now unified

[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 changed, so if you see weirdness starting today please let me know,
particularly if its in APZ, plugins, or media, which make the heaviest use
of the chromium event queue.

You can check out bug 1269056 for more details.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[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 there any risks of breaking sites with this change? I would assume 
if we're aligning with Chrome (if they follow the spec here), probably 
not. But I don't actually know.


--
Mike Taylor
Web Compat, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[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 has a track), 
plus there's a whole UX overhaul coming [1]. That's why I'm hoping we'll 
solve this better later.



Of course, the UI would not be ideal since it would likely look
different than if the user face-mutes in-app.


Note that the spec has both track.muted and track.enabled.

track.enabled ("in-app mute") means the site controls things (hopefully 
only on the user's behalf) and is relevant after users trust the site 
with their camera (a malicious site can enable it back on at any time).


track.muted ("browser-chrome-only face-mute") has more teeth from a 
privacy perspective, in that the site cannot override it.


From a permission standpoint, whether the use-case of "I trust this 
site with my microphone, but not my camera (yet), so grant permission 
but force-face-mute video for me, and I may or may not turn it on later" 
adds value to Firefox, is something we could mull over.


A tangential use-case may be "I don't have a camera, but site tells me I 
need one, so give it a fake one".


Those are the two use-cases I see lost by removal of "No video". Whether 
they're still important may need a review.



So if the spec uses a different syntax for allowing the user to
face-mute, which can be turned on/off at any time, then implementing
that mechanism and hooking into that does indeed sound better. Is that
what you're referring to with the last paragraph in the original post?


I think the spec has the bits we need, so this ultimately boils down to 
UX I think, and what we want to achieve.



/ Jonas



.: Jan-Ivar :.

[1] https://bugzil.la/1267607

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[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 more memory.

Quite the opposite actually. The overhead is negligible, but the stability 
improvement is tremendous. After switching to 64-bit I haven't crashed even 
once for several months, whereas on 32-bit I crashed several times a week.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[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 common with 64-bit builds on systems with
> > less RAM because 64-bit builds use more memory.
> >
> 
> Our OOM crashes are almost always from running out of virtual memory, not
> physical.

However, running low on physical memory is (given the existence of
swap) more likely to result in slowdowns and swapping, which are a
different set of bad symptoms from crashes.

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[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 use more memory.
>

Our OOM crashes are almost always from running out of virtual memory, not
physical.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[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
OOM-because-we-can't-find-a-one-meg-chunk-in-this-horribly-fragmented-heap
issues. In theory even if the physical memory usage gets too high we can
hope that things get paged out rather than OOMing.

So there's a reasonable argument for just upping everyone who can to 64-bit.

-e

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 use more memory.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[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
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[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 missing.

This part should be fixable by creating a video stream which just
contains black (or a "anonymous user" icon or some such).

Of course, the UI would not be ideal since it would likely look
different than if the user face-mutes in-app.

So if the spec uses a different syntax for allowing the user to
face-mute, which can be turned on/off at any time, then implementing
that mechanism and hooking into that does indeed sound better. Is that
what you're referring to with the last paragraph in the original post?

/ Jonas
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[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 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 - 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]
https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/


On Thu, May 12, 2016 at 3:12 PM, Ben Hearsum 
wrote:


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 don't see a practical way of making the decision on the server if it
requires this much information.

On 2016-05-12 01:07 PM, Ted Mielczarek wrote:


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 wrote:


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
plugins or RAM is not something we know about when serving updates.

On 2016-05-12 11: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 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 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 due to address space fragmentation since
they have
a very large address space compared to the maximum 4GB available
to the
32-bit builds.

It does seem like we'd need some minimal checking here, obviously
first
for whether the user is running 64-bit Windows, but also possibly
whether they use 32-bit plugins (until such time as we unsupport
NPAPI).
32-bit plugins will not work on a 64-bit Windows Firefox (we do
not have
the equivalent of Universal binaries like we do on OS X).

-Ted



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform




___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform





___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[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 - 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]
https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/

On Thu, May 12, 2016 at 3:12 PM, Ben Hearsum  wrote:


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 don't see a practical way of making the decision on the server if it
requires this much information.

On 2016-05-12 01:07 PM, Ted Mielczarek wrote:


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 wrote:


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
plugins or RAM is not something we know about when serving updates.

On 2016-05-12 11: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 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 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 due to address space fragmentation since they have
a very large address space compared to the maximum 4GB available to the
32-bit builds.

It does seem like we'd need some minimal checking here, obviously first
for whether the user is running 64-bit Windows, but also possibly
whether they use 32-bit plugins (until such time as we unsupport NPAPI).
32-bit plugins will not work on a 64-bit Windows Firefox (we do not have
the equivalent of Universal binaries like we do on OS X).

-Ted



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform




___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[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 camera choice "No video", and the microphone choice "No 
audio". We are removing those choices to be compliant. [2]


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.


Sites are now expected to use navigator.mediaDevices.enumerateDevices to 
query whether a user has a camera, a microphone, or both [3].


The spec does allow browsers to mute [4], so we hope to revisit ideas 
like "join face-muted" in the near future (after a UX redesign).


Questions or concerns welcome,

.: Jan-Ivar :.

[1] 
http://w3c.github.io/mediacapture-main/getusermedia.html#dom-mediadevices-getusermedia

[2] https://bugzil.la/802326
[3] 
http://stackoverflow.com/questions/25308486/make-video-stream-optional-in-getusermedia/33770858#33770858

[4] http://w3c.github.io/mediacapture-main/getusermedia.html#track-muted
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[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]
https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/

On Thu, May 12, 2016 at 3:12 PM, Ben Hearsum  wrote:

> 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 don't see a practical way of making the decision on the server if it
> requires this much information.
>
> On 2016-05-12 01:07 PM, Ted Mielczarek wrote:
>
>> 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 wrote:
>>
>>> 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
>>> plugins or RAM is not something we know about when serving updates.
>>>
>>> On 2016-05-12 11: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 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 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 due to address space fragmentation since they have
 a very large address space compared to the maximum 4GB available to the
 32-bit builds.

 It does seem like we'd need some minimal checking here, obviously first
 for whether the user is running 64-bit Windows, but also possibly
 whether they use 32-bit plugins (until such time as we unsupport NPAPI).
 32-bit plugins will not work on a 64-bit Windows Firefox (we do not have
 the equivalent of Universal binaries like we do on OS X).

 -Ted


>>> ___
>>> dev-platform mailing list
>>> dev-platform@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>>>
>>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[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 I don't see a practical way of making the decision on the 
server if it requires this much information.


On 2016-05-12 01:07 PM, Ted Mielczarek wrote:

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 wrote:

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
plugins or RAM is not something we know about when serving updates.

On 2016-05-12 11: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 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 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 due to address space fragmentation since they have
a very large address space compared to the maximum 4GB available to the
32-bit builds.

It does seem like we'd need some minimal checking here, obviously first
for whether the user is running 64-bit Windows, but also possibly
whether they use 32-bit plugins (until such time as we unsupport NPAPI).
32-bit plugins will not work on a 64-bit Windows Firefox (we do not have
the equivalent of Universal binaries like we do on OS X).

-Ted



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[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 wrote:
> 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 
> plugins or RAM is not something we know about when serving updates.
> 
> On 2016-05-12 11: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 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 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 due to address space fragmentation since they have
> > a very large address space compared to the maximum 4GB available to the
> > 32-bit builds.
> >
> > It does seem like we'd need some minimal checking here, obviously first
> > for whether the user is running 64-bit Windows, but also possibly
> > whether they use 32-bit plugins (until such time as we unsupport NPAPI).
> > 32-bit plugins will not work on a 64-bit Windows Firefox (we do not have
> > the equivalent of Universal binaries like we do on OS X).
> >
> > -Ted
> >
> 
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[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 
plugins or RAM is not something we know about when serving updates.


On 2016-05-12 11: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 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 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 due to address space fragmentation since they have
a very large address space compared to the maximum 4GB available to the
32-bit builds.

It does seem like we'd need some minimal checking here, obviously first
for whether the user is running 64-bit Windows, but also possibly
whether they use 32-bit plugins (until such time as we unsupport NPAPI).
32-bit plugins will not work on a 64-bit Windows Firefox (we do not have
the equivalent of Universal binaries like we do on OS X).

-Ted



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[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 due to address space fragmentation since they have
> a very large address space compared to the maximum 4GB available to the
> 32-bit builds.

Might it be worth considering automatically updating users on
machines with 6GB (roughly) or more of RAM, but leaving alone users
with less RAM?

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[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 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 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 due to address space fragmentation since they have
a very large address space compared to the maximum 4GB available to the
32-bit builds.

It does seem like we'd need some minimal checking here, obviously first
for whether the user is running 64-bit Windows, but also possibly
whether they use 32-bit plugins (until such time as we unsupport NPAPI).
32-bit plugins will not work on a 64-bit Windows Firefox (we do not have
the equivalent of Universal binaries like we do on OS X).

-Ted
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[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:

> How would we handle going from Program Files (x86) to Program Files? Just
> leave the install directory as-is for updates?
>
>
> On 5/12/2016 11: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 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 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 due to address space fragmentation since they have
>> a very large address space compared to the maximum 4GB available to the
>> 32-bit builds.
>>
>> It does seem like we'd need some minimal checking here, obviously first
>> for whether the user is running 64-bit Windows, but also possibly
>> whether they use 32-bit plugins (until such time as we unsupport NPAPI).
>> 32-bit plugins will not work on a 64-bit Windows Firefox (we do not have
>> the equivalent of Universal binaries like we do on OS X).
>>
>> -Ted
>>
>>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[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 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 due to address space fragmentation since they have
a very large address space compared to the maximum 4GB available to the
32-bit builds.

It does seem like we'd need some minimal checking here, obviously first
for whether the user is running 64-bit Windows, but also possibly
whether they use 32-bit plugins (until such time as we unsupport NPAPI).
32-bit plugins will not work on a 64-bit Windows Firefox (we do not have
the equivalent of Universal binaries like we do on OS X).

-Ted
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[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 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 more try push every 6 hours (fx-team and m-i
are separated by an hour) that only requests talos jobs for Linux x64
and Windows. No build cost.

IMHO the cost seems minimal, however, I will let jmaher weigh in here.

regards,
Armen

On 2016-05-12 10:16 AM, Gregory Szorc wrote:

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, Armen Zambrano G. 
wrote:

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 work done by our contributor martianwars.

regards,
Armen

[1]
https://treeherder.mozilla.org/#/jobs?repo=fx-team=8cf323be5c58b28d8719401ebb0ef63f1d71d000=pgo%20talos_state=expanded



--
Zambrano Gasparnian, Armen
Automation & Tools Engineer
http://armenzg.blogspot.ca
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform




PGO build frequency is 3 hours.



--
Zambrano Gasparnian, Armen
Automation & Tools Engineer
http://armenzg.blogspot.ca
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[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 extra jobs for Windows 7.

This is equivalent to two more try push every 6 hours (fx-team and m-i
are separated by an hour) that only requests talos jobs for Linux x64
and Windows. No build cost.

IMHO the cost seems minimal, however, I will let jmaher weigh in here.

regards,
Armen

On 2016-05-12 10:16 AM, Gregory Szorc wrote:

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, Armen Zambrano G. 
wrote:

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 work done by our contributor martianwars.

regards,
Armen

[1]
https://treeherder.mozilla.org/#/jobs?repo=fx-team=8cf323be5c58b28d8719401ebb0ef63f1d71d000=pgo%20talos_state=expanded


--
Zambrano Gasparnian, Armen
Automation & Tools Engineer
http://armenzg.blogspot.ca
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform




PGO build frequency is 3 hours.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[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 more try push every 6 hours (fx-team and m-i 
are separated by an hour) that only requests talos jobs for Linux x64 
and Windows. No build cost.


IMHO the cost seems minimal, however, I will let jmaher weigh in here.

regards,
Armen

On 2016-05-12 10:16 AM, Gregory Szorc wrote:

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, Armen Zambrano G.  wrote:

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 work done by our contributor martianwars.

regards,
Armen

[1] 
https://treeherder.mozilla.org/#/jobs?repo=fx-team=8cf323be5c58b28d8719401ebb0ef63f1d71d000=pgo%20talos_state=expanded

--
Zambrano Gasparnian, Armen
Automation & Tools Engineer
http://armenzg.blogspot.ca
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform



--
Zambrano Gasparnian, Armen
Automation & Tools Engineer
http://armenzg.blogspot.ca
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[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, Armen Zambrano G.  wrote:
> 
> 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 work done by our contributor martianwars.
> 
> regards,
> Armen
> 
> [1] 
> https://treeherder.mozilla.org/#/jobs?repo=fx-team=8cf323be5c58b28d8719401ebb0ef63f1d71d000=pgo%20talos_state=expanded
> 
> -- 
> Zambrano Gasparnian, Armen
> Automation & Tools Engineer
> http://armenzg.blogspot.ca
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[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 work done by our contributor martianwars.

regards,
Armen

[1] 
https://treeherder.mozilla.org/#/jobs?repo=fx-team=8cf323be5c58b28d8719401ebb0ef63f1d71d000=pgo%20talos_state=expanded


--
Zambrano Gasparnian, Armen
Automation & Tools Engineer
http://armenzg.blogspot.ca
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: MacOS 10.6-10.8 support

[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 06:01:12PM +1000, Xidorn Quan wrote:
> > > > >
> > > > > It's Firefox 48, three versions after ESR 45, which is roughly halfway
> > > > > before the next ESR.
> > > >
> > > > 48 is the first version that will *not* have 10.6-10.8 support.
> > >
> > >
> > > On Mon, May 2, 2016 at 2:28 PM, Ralph Giles  wrote:
> > > > The blog post just says "August 2016". Firefox 48 is scheduled for
> > > > release August 2. Can you confirm that means we can start removing
> > > > 10.6-10.8 support in mozilla-central now, which will be Firefox 49?
> > >
> > > This post reads to me that we start dropping 10.6~10.8 since Firefox 49, 
> > > so
> > > Firefox 48 should be the last one with that support. Am I missing 
> > > something
> > > here?
> > >
> > 
> > The post states "Mozilla will end support for Firefox on OS X 10.6, 10.7,
> > and 10.8 in August, 2016." This means that we will end support with the
> > Firefox 48 release. i.e. Firefox 48 will not support OS X 10.6-10.8.
> 
> That's why the post should have given a version number instead of an
> ambiguous date.
> 
> Mike

I couldn't agree more. If you do not believe people can mix up and/or confuse 
what seems like an obvious statement or instructions, have a room full of 
college students read and explain it back to you.

Any word on the ESR issue?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform