Re: Windows XP and Vista Long Term Support Plan

2016-10-31 Thread Robert Strong 
Aaron, thank you for explaining the reasons for this decision so thoroughly!

On Mon, Oct 31, 2016 at 3:48 PM, Aaron Klotz  wrote:

> Disclaimer: I am not a decision maker on this, these are my personal
> opinions, etc, etc
>
> On 10/31/2016 3:54 PM, juar...@gmail.com wrote:
>
>>
>> Discontinuing support for 10% of users sounds like shrinking 10% of
>> customers, lay off 10% of employees, reduce 10% of funds for investments.
>>
>> - Is really necessary to abandon all XP users?
>>
> Shifting XP users to ESR is different from "abandonment" FWIW, but IMHO
> this move is necessary. As I pointed out earlier in this discussion, the
> problems have become more complicated than simply disabling certain pieces
> of code when XP does not support them.
>
> - Is possible to discontinue the most hard to support components?
>> Somenthing like "Video conferencing will not work in XP" or like is planned
>> for flash.
>>
> Again, that is not the problem. The problem is more like, "Sorry 90% of
> users, we can't give you a better sandbox because of the 10% of users
> running an obsolete and unsupported OS," or "This feature is going to be
> delayed a release because it mysteriously fails on Windows XP." Meanwhile,
> our competitors *do* deliver that better sandbox or *do* release that new
> feature before we do. Now we're preserving that 10% of users at the expense
> of the other 90%, and it's in the latter category where the growth will be.
> That sounds like a pretty lousy growth strategy to me.
>
> - Is possible restrict the user base affected? Like only XP SP2 and
>> older...
>>
> Existing Firefox system requirements are for XP SP2, so we already
> restrict older revisions, but that isn't really the issue here. The issue
> is the gulf between all XP releases and newer versions.
>
> As somebody who has first-hand experience with this, let me assure you:
> Debugging XP-specific problems has become very unpleasant. Most developers
> don't just have an XP machine sitting around to work with. We can request a
> loaner from Release Engineering and debug it through there, but that is
> very tedious and time consuming. Turnaround on try builds for Windows XP is
> sometimes terribly slow. As XP continues to die off, this will only get
> worse, not better.
>
> I see how Mozilla is important for open web and how firefox user base is
>> shrinking. This worries me.
>>
> Do not confuse shrinking market share with shrinking user base. That is
> only the case when the total number of users on the web remains constant,
> which is not the case. Having said that, I don't want to see shrinking
> market share either.
>
> I do not believe that we can offer the highest quality experience to the
> vast majority of our users by continuing to expend resources on the past.
> One of our top-line goals for 2016 has been to build our core strength. I
> don't know how we're supposed to do that by intentionally tying one hand
> behind our back to support Windows XP.
>
> Supporting XP might curb short-term market share losses but it will hinder
> our ability to deliver long-term market share gains.
>
> Maybe hiring one or two developers for supporting this user base is
>> cheaper than loosing these users.
>>
>
> Hopefully my other remarks in this post have made it clear that XP support
> is not an issue of headcount.
>
> ___
> 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: Windows XP and Vista Long Term Support Plan

2016-10-31 Thread juarezr 
Em quinta-feira, 27 de outubro de 2016 11:48:13 UTC-2, Peter Dolanjski  
escreveu:
> >
> > What I think would be helpful if Mozilla does go with this plan, is that,
> > first, Mozilla sets a definite end date up front for ESR 52 and, second,
> > that Mozilla has puts out the message as to what and why this is happening.
> > Setting an end date for support will give everyone a timeline to work with
> > and kill any hope on those with older machines that they can just keep
> > holding out one more month for updates that will never come. 

Discontinuing support for 10% of users sounds like shrinking 10% of customers, 
lay off 10% of employees, reduce 10% of funds for investments.

- Is really necessary to abandon all XP users?
- Is possible to discontinue the most hard to support components? Somenthing 
like "Video conferencing will not work in XP" or like is planned for flash.
- Is possible restrict the user base affected? Like only XP SP2 and older...
- Someone has the statistics details of this "10% user base" for supporting 
this decision? What service pack? Where they are? What are the demographics 
numbers? How often the browse web?
- Someone has the numbers for what is the cost for this burden?

I see how Mozilla is important for open web and how firefox user base is 
shrinking. This worries me. 

Maybe hiring one or two developers for supporting this user base is cheaper 
than loosing these users.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: navigator.getBattery (Battery Status API)

2016-10-31 Thread Chris Peterson 

On 10/31/2016 11:23 AM, nicjan...@gmail.com wrote:

Boomerang is an open-source library [1] for collecting performance telemetry.  
You're correct that it currently captures the battery level and other device 
characteristics.  While Boomerang was not designed for the purpose of 
fingerprinting users, it captures many performance metrics and page 
characteristics on the beacon.  Boomerang also only captures battery level, not 
charging time/discharging time (which we understand to be needed for the 
fingerprinting case).  mPulse RUM itself (which is one of the services that 
utilizes Boomerang) does not do user fingerprinting -- we capture all of this 
data to look at aggregate performance.

Boomerang has been collecting the battery level in supported browsers for a 
while, but we don't consider it an essential device characteristic.  In 
aggregate, it becomes interesting -- we can tell, for example, if certain paths 
through a customer's website correlate with high battery discharge, indicating 
possible post-page-load performance issues (like too many ads).


Thanks for the explanation of Boomerang. I see how battery level would 
be an interesting data point for RUM. I don't know if the battery 
measurements would be precise enough for short browsing sessions to be 
actionable, though it might be interesting to exclude low-battery users 
as outliers with non-representative system performance. :)


Have you seen any such correlations?

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

Re: Intent to unship: navigator.getBattery (Battery Status API)

2016-10-31 Thread nicjansma 
Boomerang is an open-source library [1] for collecting performance telemetry.  
You're correct that it currently captures the battery level and other device 
characteristics.  While Boomerang was not designed for the purpose of 
fingerprinting users, it captures many performance metrics and page 
characteristics on the beacon.  Boomerang also only captures battery level, not 
charging time/discharging time (which we understand to be needed for the 
fingerprinting case).  mPulse RUM itself (which is one of the services that 
utilizes Boomerang) does not do user fingerprinting -- we capture all of this 
data to look at aggregate performance.

Boomerang has been collecting the battery level in supported browsers for a 
while, but we don't consider it an essential device characteristic.  In 
aggregate, it becomes interesting -- we can tell, for example, if certain paths 
through a customer's website correlate with high battery discharge, indicating 
possible post-page-load performance issues (like too many ads).

Obviously there are better/others ways of doing this (such as the work being 
done on the Long Tasks API), measuring FPS, etc.  But whenever things like the 
Battery API are available we love to capture all the data we can to see what 
interesting conclusions we can find out of it in our aggregate RUM data :)

That being said, if the Battery API went away we would probably shrug, and look 
forward to more actionable performance metrics such as the Long Tasks API.

PS, we know of customers and open-source users putting Boomerang on a couple 
thousand websites -- but that probably wouldn't account for 6% of page loads 
usage!

[1]https://github.com/SOASTA/boomerang
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing navigator.buildID?

2016-10-31 Thread Domenic Denicola 
On Monday, October 31, 2016 at 10:54:11 AM UTC-4, Mike Taylor wrote:
> On 10/31/16 9:16 AM, Henri Sivonen wrote:
> > On Oct 31, 2016 16:02, "Mike Taylor"  > > wrote:
> >>
> >>
> >>
> >> On 10/29/16 9:21 AM, Kohei Yoshino wrote:
> >>>
> >>> I think now is a good time to think about navigator.buildID again
> >>> Thoughts?
> >>
> >>
> >> Seems like we'd potentially end up breaking legacy sites that sniff
> > that to mean "isMozilla".
> >>
> >
> > I suggest returning a constant value to general Web sites to avoid this
> > problem.
> 
> I think that's a good path forward.
> 
> -- 
> Mike Taylor
> Web Compat, Mozilla

If Gecko has no plans to remove this and conform to the spec, could someone 
file an issue or pull request on https://github.com/whatwg/html requesting that 
buildID be added to Gecko compatibility mode? 
https://html.spec.whatwg.org/multipage/#concept-navigator-compatibility-mode
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing navigator.buildID?

2016-10-31 Thread Mike Taylor 

On 10/31/16 9:16 AM, Henri Sivonen wrote:

On Oct 31, 2016 16:02, "Mike Taylor" > wrote:




On 10/29/16 9:21 AM, Kohei Yoshino wrote:


I think now is a good time to think about navigator.buildID again
Thoughts?



Seems like we'd potentially end up breaking legacy sites that sniff

that to mean "isMozilla".




I suggest returning a constant value to general Web sites to avoid this
problem.


I think that's a good path forward.

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

Re: Removing navigator.buildID?

2016-10-31 Thread Henri Sivonen 
On Oct 31, 2016 16:02, "Mike Taylor"  wrote:
>
>
>
> On 10/29/16 9:21 AM, Kohei Yoshino wrote:
>>
>> I think now is a good time to think about navigator.buildID again
>> Thoughts?
>
>
> Seems like we'd potentially end up breaking legacy sites that sniff that
to mean "isMozilla".
>

I suggest returning a constant value to general Web sites to avoid this
problem.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing navigator.buildID?

2016-10-31 Thread Mike Taylor 



On 10/29/16 9:21 AM, Kohei Yoshino wrote:

I think now is a good time to think about navigator.buildID again
Thoughts?


Seems like we'd potentially end up breaking legacy sites that sniff that 
to mean "isMozilla".


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

Re: Removing navigator.buildID?

2016-10-31 Thread Henri Sivonen 
On Mon, Oct 31, 2016 at 3:01 PM, Aryeh Gregor  wrote:
> On Mon, Oct 31, 2016 at 10:02 AM, Chris Peterson  
> wrote:
>> Alternately, buildID could be hidden behind a domain whitelist pref, seeded
>> with sites working with Mozilla. If you are, say, a Netflix customer, they
>> already know who you are, so exposing your buildID to them is not much of a
>> tracking risk. :)
>
> If the concern is fingerprinting, perhaps it could be exposed only to
> sites that the user is logged into (assuming we have a good working
> definition of "logged in")?

I think that's over-engineering it.

I suggest we make it behave the current way for chrome,
https://*.mozilla.org and https://*.netflix.com origins and make it
return a constant otherwise.

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[desktop][mobile] Schedule Update for 50, ESR45.5 release and Merge day

2016-10-31 Thread Ritu Kothari 
Schedule change:


   - 50 go-live date is Nov 15th (was Nov 8th).
   - ESR 45.5 go-live date is Nov 15th (was Nov 8th).
   - Merge day is Nov 14th (was Nov 7th).
  - Beta 51 cycle starts ~Nov 16th
  - Aurora 52 cycle starts ~Nov 18th.
  - Beta -> Release migration is Oct 31st (remains unchanged).
   - 50.1.0 (planned dot release) go-live date of Dec 13th remains
   unchanged.
   - 51 go-live date of Jan 24th remains unchanged.

*Why the change in schedule?*

   - We decided to take two late uplifts  (in m-b yesterday) re:add-on
SDK (bugs
   1309351 and 1309350)

   - These two changes need more bake time on Beta channel.
   - RC mode for Fx50 starts on Oct 31st & we remain in code freeze mode
   for two weeks.
   - RC builds will be pushed out on an as-needed basis.

Please let me now if you have any questions or concerns.
Thanks,
Ritu
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing navigator.buildID?

2016-10-31 Thread Aryeh Gregor 
On Mon, Oct 31, 2016 at 10:02 AM, Chris Peterson  wrote:
> Alternately, buildID could be hidden behind a domain whitelist pref, seeded
> with sites working with Mozilla. If you are, say, a Netflix customer, they
> already know who you are, so exposing your buildID to them is not much of a
> tracking risk. :)

If the concern is fingerprinting, perhaps it could be exposed only to
sites that the user is logged into (assuming we have a good working
definition of "logged in")?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[Firefox Desktop] Issues found: October 24th to October 28th

2016-10-31 Thread Cornel Ionce 

Hi everyone,

Here's the list of new issues found and filed by the Desktop Release QA 
Team last week, *October 24**- October 28* (week 43).


Additional details on the team's priorities last week, as well as the 
plans for the current week are available at:


   https://public.etherpad-mozilla.org/p/DesktopManualQAWeeklyStatus


*RELEASE CHANNEL*
none

*BETA CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1313080 
 	Aliased search 
engine searches are not accounted in about:telemetry 	Firefox

Location Bar
	YES 
 
	Marco Bonardo 

1313664 
	White flashes displayed on Pinterest while scrolling using END and HOME 
keys 	Firefox

Keyboard Navigation
NO  NOBODY


*AURORA CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1312706 
Pause button becomes inactive   Firefox
Download Panel
NO  NOBODY


*NIGHTLY CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1312672 
	The Network Throttling selection and the drop down button are not 
vertically centered

Firefox
Developer Tools: Responsive Design Mode
NO  NOBODY
1313337 
	The searched string from the Find bar is deleted when 
enabling/disabling the RDM tool

Firefox Developer Tools: Responsive Design Mode NO  
NOBODY
1313645 
Login page displayed without CSS for couple of seconds on pinterest.com
Core
Layout
YES  NOBODY
1313646 
Flickering when clicking on header menu buttons on 
http://theswishlife.com
	Core 	Layout 	YES 
 	NOBODY

1313647 
	Text resized after clicking on header menu buttons on 
http://www.dwutygodnik.com
	Core 	Layout 	YES 
 	NOBODY




*ESR CHANNEL*
none

Regards,
Cornel Ionce
Team Lead
SOFTVISION

The content of this communication is classified as SOFTVISION 
Confidential and Proprietary Information.



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

Intent to unship: navigator.getBattery (Battery Status API)

2016-10-31 Thread Chris Peterson 
As proposed earlier on the dev-platform list [1], I made the Battery 
Status API chrome-only in Firefox Nightly 52 (bug 1313580 [2]). The 
battery code and tests remain, available to Gecko code and Firefox add-ons.


There should be little risk of web compat regressions. The battery API 
was never implemented by IE, Edge, or Safari, so web content should 
already be feature-detecting the API. Also, I know of no non-trivial 
websites using the API for anything other than fingerprinting users in 
the four years since Firefox introduced the API in 2012 (Firefox 10 
[3]). Chrome added support in 2014.


We always have the option to make the API available to web content again 
if a website or app demonstrates an interesting use case using Chrome's 
battery API. However, I feel the supposed use cases for the battery API 
would be better served by something like a lifecycle event API that 
includes low battery/memory warnings. That would expose less identifying 
information and allow the user and UA to customize the lifecycle settings.



[1] 
https://groups.google.com/d/msg/mozilla.dev.platform/5U8NHoUY-1k/9ybyzQIYCAAJ

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1313580
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=678694
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing navigator.buildID?

2016-10-31 Thread Chris Peterson 

On 10/30/2016 2:27 AM, Pascal Chevrel wrote:

IMO the builID is important for our community of nightly testers that
report bug and need to indicate precisely in which build they found a
regression, so keeping that information available via about:support and
extensions such as Nightly Testers Tools seems valuable for mozilla to
me in a chrome context.


Limiting navigator.buildID to chrome context is a simple change: just 
add the "ChromeOnly" annotation to buildID's webidl [1] and fix any 
fallout like DOM test [2].


However, the Gecko Media Playback team and Netflix still use buildID 
(collected by Netflix's video player JavaScript) to identify regressions 
and verify bug fixes. I believe they mostly watch the Firefox Beta 
channel (because there are too few Netflix customers on Nightly and Dev 
Edition) to verify bug fixes. We could limit buildID to pre-release 
channels, but those channels are where buildID exposes the most unique 
entropy (because every day's build has a new buildID). All Firefox 
Release channel users (for a given OS and Firefox dot-release) have the 
same buildID.


Alternately, buildID could be hidden behind a domain whitelist pref, 
seeded with sites working with Mozilla. If you are, say, a Netflix 
customer, they already know who you are, so exposing your buildID to 
them is not much of a tracking risk. :)



[1] 
http://searchfox.org/mozilla-central/source/dom/webidl/Navigator.webidl#187
[2] 
http://searchfox.org/mozilla-central/source/dom/tests/mochitest/bugs/test_bug351601.html#24

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