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

[L. David Baron]

On Friday 2016-05-13 13:10 -0700, Andrew McCreight wrote:
> On 64-bit systems, pointers take 8 bytes of memory instead of 4. A lot of
> the contents of memory is pointers. Thus a 64-bit build consumes more
> memory for a given workload. It isn't as bad as, say, twice as much memory,
> but it is enough that if you are close to the limits of your system it
> could cause problems.

On the flip side, it does make sense that the point where 64-bit
builds become better memory-wise than 32-bit builds could be
substantially below 4GB of RAM, given that 32-bit builds can run out
of memory due to fragmentation of the address space.  Where the
tradeoff lies is probably best determined by experiment.

(There are also presumably some security improvements with 64-bit.)

-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: Reverting to VS2013 on central and aurora

[Jim Blandy]

Since we didn't require SSE2 in 32-bit builds until this point, were
floating-point results rounded unpredictably in those builds until now?


On Fri, May 13, 2016 at 1:42 PM, Benjamin Smedberg 
wrote:

> I am talking about requiring SSE2. That is a larger (but still quite small)
> population, but the upside of being able to turn on SSE2 optimizations by
> default is an important benefit. I've discussed and confirmed this with
> Firefox product management.
>
> So yes, the plan of record is to require SSE2 starting in Firefox 49, and I
> will update the tracking bugs to reflect that.
>
> --BDS
>
> On Fri, May 6, 2016 at 1:17 PM, Gregory Szorc  wrote:
>
> > On Fri, May 6, 2016 at 9:39 AM, Benjamin Smedberg  >
> > wrote:
> >
> >> I agree that we should drop support for non-SSE2. It mattered 7 years
> ago
> >> (see https://bugzilla.mozilla.org/show_bug.cgi?id=500277) but it really
> >> doesn't matter now.
> >>
> >
> > Wait - are we talking about requiring SSE or SSE2? The thread up to this
> > point was talking about requiring just SSE, not SSE2. I just want to make
> > sure we're on the same page since according to mhoye's post the non-SSE2
> > population is ~25x larger than the non-SSE population...
> >
> >
> >>
> >> We do need to avoid updating these users to a build that will crash, and
> >> do the same "unsupported" messaging we're doing for old versions of
> MacOS.
> >> Gregory, will you own that? You will probably need to add CPU feature
> >> detection to the update URL/params for 47, or use some kind of system
> addon
> >> to shunt these users off the main update path.
> >>
> >
> > Given that 47 is in Beta, is it too late/risky to make this change on
> that
> > channel? Should we revert to VS2013 on Aurora/48 and make the updater
> > modifications on that channel? I think this will have minimal negative
> > impact, as most of the impact to changing toolchains would be on central,
> > as that is where most developers and automation live.
> >
> >
> >>
> >> On Fri, May 6, 2016 at 10:10 AM, Mike Hoye  wrote:
> >>
> >>> On 2016-05-06 12:26 AM, Gregory Szorc wrote:
> >>>
>  FWIW, the crashes we've seen so far are from incorrectly emitted movss
>  instructions. This instruction is part of the original SSE instruction
>  set,
>  which was initially unveiled by Intel on the Pentium 3 in 1999 and
>  later by
>  AMD on the Duron and Athlon XP in 2000-2001. I'm not sure why we still
>  need
>  Firefox to run on processors manufactured in the 90s.
> 
> >>> Per an IRC conversation with chutten, Firefox users on CPUs that do not
> >>> support SSE are 0.015% of our user base. (compared to 0.4% for
> no-SSE2). A
> >>> third of those are on otherwise-unsupported configurations (pre-SP3 XP,
> >>> etc), this work provides continuity of support to 0.01% of our users.
> >>>
> >>> - mhoye
> >>>
> >>>
> >>> 09:59  So, to put it clearly and precisely, of the Firefox
> >>> Population in release and beta who are reporting at least base
> telemetry
> >>> collection on machines running supported configurations, only 0.01%
> cannot
> >>> definitively say they have SSE.
> >>> 10:00  (according to a 1% random sample as stored in the
> >>> longitudinal dataset)
> >>>
> >>> ___
> >>> 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: Intent to deprecate: MacOS 10.6-10.8 support

[Benjamin Smedberg]

The actual content of the page is not final, but I did include that
recommendation in my request for a SUMO page. See
https://bugzilla.mozilla.org/show_bug.cgi?id=1270221

--BDS

On Fri, May 13, 2016 at 4:59 PM, Adam Roach  wrote:

> On 5/13/16 14:26, Ben Hearsum wrote:
>
>> I intend to make sure that Beta/Release/ESR is configured in such a way
>> that users get the most up to date release possible. Eg: serve 10.6-10.8
>> users the latest 48.0 point release, then give them a deprecation notice.
>>
>
> Presumably, the deprecation notice will mention ESR as a way to continue
> to get security updates for several more months?
>
>
> --
> Adam Roach
> Principal Platform Engineer
> Office of the CTO
>
> ___
> 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: Intent to deprecate: MacOS 10.6-10.8 support

[Adam Roach]

On 5/13/16 14:26, Ben Hearsum wrote:
I intend to make sure that Beta/Release/ESR is configured in such a 
way that users get the most up to date release possible. Eg: serve 
10.6-10.8 users the latest 48.0 point release, then give them a 
deprecation notice. 


Presumably, the deprecation notice will mention ESR as a way to continue 
to get security updates for several more months?



--
Adam Roach
Principal Platform Engineer
Office of the CTO
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Reverting to VS2013 on central and aurora

[Benjamin Smedberg]

I am talking about requiring SSE2. That is a larger (but still quite small)
population, but the upside of being able to turn on SSE2 optimizations by
default is an important benefit. I've discussed and confirmed this with
Firefox product management.

So yes, the plan of record is to require SSE2 starting in Firefox 49, and I
will update the tracking bugs to reflect that.

--BDS

On Fri, May 6, 2016 at 1:17 PM, Gregory Szorc  wrote:

> On Fri, May 6, 2016 at 9:39 AM, Benjamin Smedberg 
> wrote:
>
>> I agree that we should drop support for non-SSE2. It mattered 7 years ago
>> (see https://bugzilla.mozilla.org/show_bug.cgi?id=500277) but it really
>> doesn't matter now.
>>
>
> Wait - are we talking about requiring SSE or SSE2? The thread up to this
> point was talking about requiring just SSE, not SSE2. I just want to make
> sure we're on the same page since according to mhoye's post the non-SSE2
> population is ~25x larger than the non-SSE population...
>
>
>>
>> We do need to avoid updating these users to a build that will crash, and
>> do the same "unsupported" messaging we're doing for old versions of MacOS.
>> Gregory, will you own that? You will probably need to add CPU feature
>> detection to the update URL/params for 47, or use some kind of system addon
>> to shunt these users off the main update path.
>>
>
> Given that 47 is in Beta, is it too late/risky to make this change on that
> channel? Should we revert to VS2013 on Aurora/48 and make the updater
> modifications on that channel? I think this will have minimal negative
> impact, as most of the impact to changing toolchains would be on central,
> as that is where most developers and automation live.
>
>
>>
>> On Fri, May 6, 2016 at 10:10 AM, Mike Hoye  wrote:
>>
>>> On 2016-05-06 12:26 AM, Gregory Szorc wrote:
>>>
 FWIW, the crashes we've seen so far are from incorrectly emitted movss
 instructions. This instruction is part of the original SSE instruction
 set,
 which was initially unveiled by Intel on the Pentium 3 in 1999 and
 later by
 AMD on the Duron and Athlon XP in 2000-2001. I'm not sure why we still
 need
 Firefox to run on processors manufactured in the 90s.

>>> Per an IRC conversation with chutten, Firefox users on CPUs that do not
>>> support SSE are 0.015% of our user base. (compared to 0.4% for no-SSE2). A
>>> third of those are on otherwise-unsupported configurations (pre-SP3 XP,
>>> etc), this work provides continuity of support to 0.01% of our users.
>>>
>>> - mhoye
>>>
>>>
>>> 09:59  So, to put it clearly and precisely, of the Firefox
>>> Population in release and beta who are reporting at least base telemetry
>>> collection on machines running supported configurations, only 0.01% cannot
>>> definitively say they have SSE.
>>> 10:00  (according to a 1% random sample as stored in the
>>> longitudinal dataset)
>>>
>>> ___
>>> 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?

[Benjamin Smedberg]

We have considered this, but in the grand rollout plans for 64-bit Firefox
it's low on the list. We're still dealing with Flash sandboxing/functional
regressions as a blocker for wider rollout, and the next step is probably
to progressively roll out win64 to new users before we consider anything
for existing users.

This will be much easier now that we have widevine and are dropping
npapi/silverlight, but addon compat is also a concern and we wanted to
partly wait for webextensions before pushing more on this.

--BDS

On Thu, May 12, 2016 at 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: Intent to deprecate: MacOS 10.6-10.8 support

[Benjamin Smedberg]

I didn't know we intended to drop support in 48. I just assumed 49 from
reading the blog post and knowing that things were just landing in nightly.
At this point, though, I don't want to do uplifts and would prefer that
this ride the 49 train.

--BDS

On Fri, May 13, 2016 at 3:24 PM, Ben Hearsum  wrote:

> Thanks for clarifying. It seems like the confusion came from the fact that
> we had *intended* to drop support in 48.0, but it hadn't happened yet. And
> now we don't *intend* to drop support until 49.0?
>
> On 2016-05-13 02:55 PM, Benjamin Smedberg wrote:
>
>> Right now the code to disable 10.6 has landed only on nightly/49, and
>> other
>> bits are still blocked (see bug 1270217) because our MacOS builders (not
>> the testers) are still running MacOS 10.7. As of this point, I expect that
>> Firefox 48 will still run on 10.6-10.8 and the first release to drop
>> support will be Fx49.
>>
>> If anyone wants to follow along, the tracking bug for the various pieces
>> of
>> client, updater, website, and SUMO changes are being tracked in bug
>> 1255589.
>>
>> --BDS
>>
>> On Fri, May 13, 2016 at 2:15 PM, Nils Ohlmeier 
>> wrote:
>>
>>
>>> On May 10, 2016, at 19:58, Lawrence Mandel  wrote:

 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.

>>>
>>> Why do Firefox DevEdition users on Mac OS X 10.6 then still get updates
>>> to
>>> DevEd 48?
>>>
>>> I just tested it on a 10.6 machine and updates have stopped for Nightly.
>>> Which is good, because the Nightly 49 build which I manually downloaded
>>> crashes and brings up the Mac OS X crash reporter.
>>> But the DevEdition installed on the same system updated itself to 48. And
>>> 48 started and appeared to be still working.
>>>
>>> Best
>>>Nils Ohlmeier
>>>
>>> ___
>>> 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?

[Andrew McCreight]

On Fri, May 13, 2016 at 1:02 PM,  wrote:

> Why do you developers keep insisting breathlessly that 64-bit builds are
> memory hogs? I'm a power user who has 3 windows and 1,565 tabs open. I have
> a 4 GB laptop and a 16 GB desktop replaced a 6 GB desktop. I like to think
> that I use Firefox close to its breaking point. On any given day, Firefox
> takes between 2.4 GB and 3.1 GB no matter whether it was the 32-bit build
> or is the 64-bit build. Only one time while I was using the 64-bit build
> did I notice it climb on its own all the way up to 5.9 GB, but then the
> memory was released and it settled down to 3.l GB again and, I repeat, that
> was only ONE TIME. Microsoft has a 64-bit version of Edge that I use. Also,
> I downloaded the 64-bit beta version of Google Chrome and use it with
> little problem compared to its 32-bit version. Under what I consider normal
> circumstances, I just don't see 64-bit versions eating memory like Mozilla
> developers keep insisting they do.
>

On 64-bit systems, pointers take 8 bytes of memory instead of 4. A lot of
the contents of memory is pointers. Thus a 64-bit build consumes more
memory for a given workload. It isn't as bad as, say, twice as much memory,
but it is enough that if you are close to the limits of your system it
could cause problems.

Andrew



>
> Now to be fair, I understand not wanting to put the 64-bit version of
> Firefox on low memory systems. I left the 32-bit version on my 4 GB laptop.
> I would personally say that x64 OS's with 6GB or more memory should be able
> to be upgraded to the 64-bit version of Firefox.  After NPAPI support goes
> away, there really should be no excuse to leave such systems on the 32-bit
> version as the 32-bit version doesn't take advantage of all of the 64-bit
> OS features and 64-bit processor's features. And as I have said previously,
> the 64-bit version is way more stable than the 32-bit version.
> ___
> 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?

[keithgallistel]

On Friday, May 13, 2016 at 7:35:52 AM UTC-5, Ben Hearsum wrote:
> On 2016-05-12 06:44 PM, khagar...@gmail.com wrote:
> > 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.
> >
> 
> How much RAM do you have? 64-bit builds should use more memory than 
> 32-bit builds under the same circumstances. As others in this thread 
> have noted, this can lead to easier OOM crashes and slowness to due 
> additional swapping. If you have a bunch of RAM these downsides go away.

Why do you developers keep insisting breathlessly that 64-bit builds are memory 
hogs? I'm a power user who has 3 windows and 1,565 tabs open. I have a 4 GB 
laptop and a 16 GB desktop replaced a 6 GB desktop. I like to think that I use 
Firefox close to its breaking point. On any given day, Firefox takes between 
2.4 GB and 3.1 GB no matter whether it was the 32-bit build or is the 64-bit 
build. Only one time while I was using the 64-bit build did I notice it climb 
on its own all the way up to 5.9 GB, but then the memory was released and it 
settled down to 3.l GB again and, I repeat, that was only ONE TIME. Microsoft 
has a 64-bit version of Edge that I use. Also, I downloaded the 64-bit beta 
version of Google Chrome and use it with little problem compared to its 32-bit 
version. Under what I consider normal circumstances, I just don't see 64-bit 
versions eating memory like Mozilla developers keep insisting they do.

Now to be fair, I understand not wanting to put the 64-bit version of Firefox 
on low memory systems. I left the 32-bit version on my 4 GB laptop. I would 
personally say that x64 OS's with 6GB or more memory should be able to be 
upgraded to the 64-bit version of Firefox.  After NPAPI support goes away, 
there really should be no excuse to leave such systems on the 32-bit version as 
the 32-bit version doesn't take advantage of all of the 64-bit OS features and 
64-bit processor's features. And as I have said previously, the 64-bit version 
is way more stable than the 32-bit version.
___
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

[Lawrence Mandel]

Yes. The intention was 48.0. Given that that doesn't actually buy us
anything at this point, dropping support in 49.0 is fine.

Lawrence

On Fri, May 13, 2016 at 3:24 PM, Ben Hearsum  wrote:

> Thanks for clarifying. It seems like the confusion came from the fact that
> we had *intended* to drop support in 48.0, but it hadn't happened yet. And
> now we don't *intend* to drop support until 49.0?
>
> On 2016-05-13 02:55 PM, Benjamin Smedberg wrote:
>
>> Right now the code to disable 10.6 has landed only on nightly/49, and
>> other
>> bits are still blocked (see bug 1270217) because our MacOS builders (not
>> the testers) are still running MacOS 10.7. As of this point, I expect that
>> Firefox 48 will still run on 10.6-10.8 and the first release to drop
>> support will be Fx49.
>>
>> If anyone wants to follow along, the tracking bug for the various pieces
>> of
>> client, updater, website, and SUMO changes are being tracked in bug
>> 1255589.
>>
>> --BDS
>>
>>
>> On Fri, May 13, 2016 at 2:15 PM, Nils Ohlmeier 
>> wrote:
>>
>>
>>> On May 10, 2016, at 19:58, Lawrence Mandel  wrote:

 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.

>>>
>>> Why do Firefox DevEdition users on Mac OS X 10.6 then still get updates
>>> to
>>> DevEd 48?
>>>
>>> I just tested it on a 10.6 machine and updates have stopped for Nightly.
>>> Which is good, because the Nightly 49 build which I manually downloaded
>>> crashes and brings up the Mac OS X crash reporter.
>>> But the DevEdition installed on the same system updated itself to 48. And
>>> 48 started and appeared to be still working.
>>>
>>> Best
>>>Nils Ohlmeier
>>>
>>> ___
>>> 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: Intent to deprecate: MacOS 10.6-10.8 support

[Ben Hearsum]

This was discussed in 
https://bugzilla.mozilla.org/show_bug.cgi?id=1269811#c7. It's 
technically possible to do, but it didn't seem worthwhile on Nightly and 
Aurora.


I intend to make sure that Beta/Release/ESR is configured in such a way 
that users get the most up to date release possible. Eg: serve 10.6-10.8 
users the latest 48.0 point release, then give them a deprecation notice.


On 2016-05-13 02:52 PM, Benjamin Smedberg wrote:

Nils, feel free to file a bug on this and cc bhearsum. I don't know how
much work this would be.

--BDS

On Fri, May 13, 2016 at 2:18 PM, Nils Ohlmeier 
wrote:




On May 3, 2016, at 15:18, Adam Roach  wrote:

On 5/3/16 4:59 PM, Justin Dolske wrote:

On 5/3/16 12:21 PM, Gregory Szorc wrote:


* The update server has been reconfigured to not serve Nightly updates

to

10.6-10.8 (bug 1269811)


Are we going to be showing some kind of notice to affected users upon

Release? That is, if I'm a 10.6 user and I update to Firefox 48, at some
point should I see a message saying I'll no longer receive future updates?


Even better, is there any way to get the update system to automatically

move such users over to 45ESR?

I agree. At least users should get updated to the latest version in their
channel. If not automatically or getting pointed to manually switch to the
latest secure release for their version/channel.

Right now I started a Nightly 40 on 10.6.8 and it simply refused to do any
update at all. That is less then ideal I would say.

Best regards
   Nils Ohlmeier

___
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: Intent to deprecate: MacOS 10.6-10.8 support

[Ben Hearsum]

Thanks for clarifying. It seems like the confusion came from the fact 
that we had *intended* to drop support in 48.0, but it hadn't happened 
yet. And now we don't *intend* to drop support until 49.0?


On 2016-05-13 02:55 PM, Benjamin Smedberg wrote:

Right now the code to disable 10.6 has landed only on nightly/49, and other
bits are still blocked (see bug 1270217) because our MacOS builders (not
the testers) are still running MacOS 10.7. As of this point, I expect that
Firefox 48 will still run on 10.6-10.8 and the first release to drop
support will be Fx49.

If anyone wants to follow along, the tracking bug for the various pieces of
client, updater, website, and SUMO changes are being tracked in bug 1255589.

--BDS

On Fri, May 13, 2016 at 2:15 PM, Nils Ohlmeier 
wrote:




On May 10, 2016, at 19:58, Lawrence Mandel  wrote:

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.


Why do Firefox DevEdition users on Mac OS X 10.6 then still get updates to
DevEd 48?

I just tested it on a 10.6 machine and updates have stopped for Nightly.
Which is good, because the Nightly 49 build which I manually downloaded
crashes and brings up the Mac OS X crash reporter.
But the DevEdition installed on the same system updated itself to 48. And
48 started and appeared to be still working.

Best
   Nils Ohlmeier

___
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: Intent to deprecate: MacOS 10.6-10.8 support

[Benjamin Smedberg]

Nils, feel free to file a bug on this and cc bhearsum. I don't know how
much work this would be.

--BDS

On Fri, May 13, 2016 at 2:18 PM, Nils Ohlmeier 
wrote:

>
> > On May 3, 2016, at 15:18, Adam Roach  wrote:
> >
> > On 5/3/16 4:59 PM, Justin Dolske wrote:
> >> On 5/3/16 12:21 PM, Gregory Szorc wrote:
> >>
> >>> * The update server has been reconfigured to not serve Nightly updates
> to
> >>> 10.6-10.8 (bug 1269811)
> >>
> >> Are we going to be showing some kind of notice to affected users upon
> Release? That is, if I'm a 10.6 user and I update to Firefox 48, at some
> point should I see a message saying I'll no longer receive future updates?
> >
> > Even better, is there any way to get the update system to automatically
> move such users over to 45ESR?
>
> I agree. At least users should get updated to the latest version in their
> channel. If not automatically or getting pointed to manually switch to the
> latest secure release for their version/channel.
>
> Right now I started a Nightly 40 on 10.6.8 and it simply refused to do any
> update at all. That is less then ideal I would say.
>
> Best regards
>   Nils Ohlmeier
>
> ___
> 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: Intent to deprecate: MacOS 10.6-10.8 support

[Benjamin Smedberg]

Right now the code to disable 10.6 has landed only on nightly/49, and other
bits are still blocked (see bug 1270217) because our MacOS builders (not
the testers) are still running MacOS 10.7. As of this point, I expect that
Firefox 48 will still run on 10.6-10.8 and the first release to drop
support will be Fx49.

If anyone wants to follow along, the tracking bug for the various pieces of
client, updater, website, and SUMO changes are being tracked in bug 1255589.

--BDS

On Fri, May 13, 2016 at 2:15 PM, Nils Ohlmeier 
wrote:

>
> > On May 10, 2016, at 19:58, Lawrence Mandel  wrote:
> >
> > 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.
>
> Why do Firefox DevEdition users on Mac OS X 10.6 then still get updates to
> DevEd 48?
>
> I just tested it on a 10.6 machine and updates have stopped for Nightly.
> Which is good, because the Nightly 49 build which I manually downloaded
> crashes and brings up the Mac OS X crash reporter.
> But the DevEdition installed on the same system updated itself to 48. And
> 48 started and appeared to be still working.
>
> Best
>   Nils Ohlmeier
>
> ___
> 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: Intent to deprecate: MacOS 10.6-10.8 support

[Nils Ohlmeier]

> On May 10, 2016, at 19:58, Lawrence Mandel  wrote:
> 
> 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.

Why do Firefox DevEdition users on Mac OS X 10.6 then still get updates to 
DevEd 48?

I just tested it on a 10.6 machine and updates have stopped for Nightly. Which 
is good, because the Nightly 49 build which I manually downloaded crashes and 
brings up the Mac OS X crash reporter.
But the DevEdition installed on the same system updated itself to 48. And 48 
started and appeared to be still working.

Best
  Nils Ohlmeier


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

[Nils Ohlmeier]

> On May 3, 2016, at 15:18, Adam Roach  wrote:
> 
> On 5/3/16 4:59 PM, Justin Dolske wrote:
>> On 5/3/16 12:21 PM, Gregory Szorc wrote:
>> 
>>> * The update server has been reconfigured to not serve Nightly updates to
>>> 10.6-10.8 (bug 1269811)
>> 
>> Are we going to be showing some kind of notice to affected users upon 
>> Release? That is, if I'm a 10.6 user and I update to Firefox 48, at some 
>> point should I see a message saying I'll no longer receive future updates?
> 
> Even better, is there any way to get the update system to automatically move 
> such users over to 45ESR?

I agree. At least users should get updated to the latest version in their 
channel. If not automatically or getting pointed to manually switch to the 
latest secure release for their version/channel.

Right now I started a Nightly 40 on 10.6.8 and it simply refused to do any 
update at all. That is less then ideal I would say.

Best regards
  Nils Ohlmeier


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Windows 7 tests in AWS

[Kyle Huey]

On Fri, May 13, 2016 at 11:07 AM, Chris AtLee  wrote:

> I'm very happy to let you know that we've recently started running some of
> our Windows 7 tests in AWS. Currently we're running these suites in Amazon
> for all branches of gecko 49 and higher:
> * Web platform tests + reftests
> * gtest
> * cppunit
> * jittest
> * jsreftest
> * crashtest
>
> Since these are now working in AWS, it means we can scale up the number of
> machines with load. This should mean a big improvement in getting test
> results back for Windows 7!
>

<3


> Work is being tracked in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1271355.
>
> If you find any issues, please reach out in #releng, or file a bug and link
> it to the one above.
>
> Thanks in particular to jmaher and Q for helping to get this work done.
>
> Cheers,
> Chris
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

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

Windows 7 tests in AWS

[Chris AtLee]

I'm very happy to let you know that we've recently started running some of
our Windows 7 tests in AWS. Currently we're running these suites in Amazon
for all branches of gecko 49 and higher:
* Web platform tests + reftests
* gtest
* cppunit
* jittest
* jsreftest
* crashtest

Since these are now working in AWS, it means we can scale up the number of
machines with load. This should mean a big improvement in getting test
results back for Windows 7!

Work is being tracked in
https://bugzilla.mozilla.org/show_bug.cgi?id=1271355.

If you find any issues, please reach out in #releng, or file a bug and link
it to the one above.

Thanks in particular to jmaher and Q for helping to get this work done.

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

Re: Intent to implement & ship: support for a subset of -webkit prefixed CSS properties & features

[Daniel Holbert]

On 05/13/2016 10:49 AM, Jet Villegas wrote:
> If I'm reading the dependency list correctly, we still plan to uplift to
> 48 if we can get bug 1264905 fixed in time. Is that correct?

bug 1264905's fix (a pref-unguarding) was just landed, as well.

We could uplift both, if we *also* uplift bug 1269971 (which was just
fixed yesterday, and which bug 1264905 depends on).

I'm instinctively uneasy about that, since that bug (bug 1269971) is
basically a reimplementation of the feature in question.
(background-clip:text)

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

Re: Intent to implement & ship: support for a subset of -webkit prefixed CSS properties & features

[Jet Villegas]

If I'm reading the dependency list correctly, we still plan to uplift to 48
if we can get bug 1264905 fixed in time. Is that correct?

--Jet

On Fri, May 13, 2016 at 10:15 AM, Daniel Holbert 
wrote:

> On 12/30/2015 10:40 PM, Daniel Holbert wrote:
> > Estimated or target release:
> >   Firefox 46 (current Nightly), or 47 if we need to hold it back a
> > release to fix things.
> >
> > Preference behind which this will be implemented:
> >   layout.css.prefixes.webkit
>
> Following up on this -- this feature will be default-enabled in Firefox
> 49, as of the pref-unguarding-patch that I just landed on this bug:
>   https://bugzilla.mozilla.org/show_bug.cgi?id=1259345
>
> (This feature has been enabled & getting very useful testing & having
> bugs filed in Nightly/Aurora ever since Firefox 46. At this point, we've
> fixed all known regressions that are triggered by this feature, so we're
> calling it safe to ship in Firefox 49, and we'll be watching for any
> more bugs that are reported.)
>
> Thanks,
> ~Daniel
> ___
> 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: Intent to implement & ship: support for a subset of -webkit prefixed CSS properties & features

[Daniel Holbert]

On 12/30/2015 10:40 PM, Daniel Holbert wrote:
> Estimated or target release:
>   Firefox 46 (current Nightly), or 47 if we need to hold it back a
> release to fix things.
> 
> Preference behind which this will be implemented:
>   layout.css.prefixes.webkit

Following up on this -- this feature will be default-enabled in Firefox
49, as of the pref-unguarding-patch that I just landed on this bug:
  https://bugzilla.mozilla.org/show_bug.cgi?id=1259345

(This feature has been enabled & getting very useful testing & having
bugs filed in Nightly/Aurora ever since Firefox 46. At this point, we've
fixed all known regressions that are triggered by this feature, so we're
calling it safe to ship in Firefox 49, and we'll be watching for any
more bugs that are reported.)

Thanks,
~Daniel
___
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 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 right when the track is 
missing.


Fixing sites sounds good.

Are there any risks of breaking sites with this change?


Firefox users may complain that some sites that used to let them join a 
call with only audio, now require them to share their camera.


We can point to Chrome, but permissions is a point of differentiation 
(we like to say we offer more privacy choices).


I would assume if we're aligning with Chrome (if they follow the spec 
here), probably not. But I don't actually know.


Chrome follows the spec, except in the case where the user has no 
camera, and a site asks for both. In that case, Chrome gives out an 
audio-only stream, just like Firefox. A bug I suspect, since it's a spec 
violation, but not 100% sure. Regardless, after we change this, we'll be 
stricter than Chrome in this edge-case.


.: Jan-Ivar :.

___
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]

On 2016-05-12 06:44 PM, khagar...@gmail.com wrote:

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.



How much RAM do you have? 64-bit builds should use more memory than 
32-bit builds under the same circumstances. As others in this thread 
have noted, this can lead to easier OOM crashes and slowness to due 
additional swapping. If you have a bunch of RAM these downsides go away.

___
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?

[keithgallistel]

On Thursday, May 12, 2016 at 5:44:32 PM UTC-5, khag...@gmail.com wrote:
> 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.

That's been my experience as well. I found out that Mozilla had started 64-bit 
versions for the beta channel, so I uninstalled my 32-bit version and installed 
the 64-bit version. I also use to have several OOM's a week with the 32-bit 
version and with the 64-bit version I have had none. The stability of the 
64-bit version is impressive. Also, memory usage isn't all that different for 
me as well. As soon as Mozilla irons out all the critical bugs and end NPAPI 
support, it really should upgrade every one it thinks would benefit to the 
64-bit version.
___
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?

[bowen]

On Thursday, 12 May 2016 21:36:53 UTC+1, Chris Peterson  wrote:
> 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.

As Flash Player doesn't provide Protected Mode for 64-bit, we've enabled our 
own sandbox.
Unfortunately this causes some regressions as the Flash DLL was never designed 
to be sandboxed when run in process like this. We'd like to strengthen the 
policy, but that breaks too many things.

So, we'd have to think carefully before deciding who we could move.
 
> 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.

Confusingly the 64-bit version lives in System32 and the 32-bit version in 
SysWOW64.
This is Microsoft's confusion not Adobe's.
SysWOW64 generally contains files used for running 32-bit binaries on 64-bit 
Windows (WOW64 is Windows [32-bit] On Windows 64[-bit])
System32 is just a legacy naming hangover as I understand, because too many 
application depended on it.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform