Re: Are we in favour of implementing the client hints header?

[Jonas Sicking]

I filed

https://github.com/httpwg/http-extensions/issues/155
https://github.com/httpwg/http-extensions/issues/156

/ Jonas

On Thu, Mar 10, 2016 at 3:07 PM,   wrote:
> Hey Jonas,
>
> Please feel free to raise issues:
>   https://github.com/httpwg/http-extensions/labels/client-hints
>
> Cheers,
> ___
> 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: W3C WebAppSec credentialmanagement API

[Martin Thomson]

On Fri, Mar 11, 2016 at 5:56 AM, Axel Nennker  wrote:
> no password generation help by the UA

I agree with MattN here, not doing this eliminates much of the
advantage of having a password manager.  Or do you have a plan to rely
on sites doing that with CredentialContainer.store()?  That doesn't
sound optimal to me.
___
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

[Hubert Figuière]

On 10/03/16 06:17 PM, Trevor Saunders wrote:
> given they haven't upgraded from 10.6 - 10.8 why do you believe they are
> likely to in the future?

1. their machine can die and they'll replace it with a new one that will
come with the latest MacOS, and restore their data from a Time Machine
backup.

2. they have some software that is important that require an update so
they will update - and since only updating to that latest OS is easy,
that's what they'll pick.

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

[Tyler Downer]

I'm not making any claims other than pointing out that the upgrade is
possible for some users, and its a workaround we can give in SUMO. I
have no other irons in this fire, just making sure we know the
workarounds (and how accessible they are) is an important piece of
this  decision.

As has been stated in this thread already, not all these users can
update, not all will, but they likely are some that just haven't
gotten around to it where upgrading is a good workaround.

On 3/10/16, Trevor Saunders  wrote:
> On Thu, Mar 10, 2016 at 04:01:15PM -0700, Tyler Downer wrote:
>> The other thing to note is many of those users can still update to 10.11,
>> and I imagine that over the next year that number will continue to go
>> down.
>
> given they haven't upgraded from 10.6 - 10.8 why do you believe they are
> likely to in the future?
>
> Trev
>
>> This also provides a decent workaround that our support community can
>> recommend in documentation and the forums.
>>
>> On Thu, Mar 10, 2016 at 3:50 PM, Ryan VanderMeulen <
>> rvandermeu...@mozilla.com> wrote:
>>
>> > 25% is pretty close for 10.6-10.8 combined. However, the current
>> > proposal
>> > includes security patches for nearly a year still (putting them on the
>> > ESR45 train), so construing this as abandoning those users seems like
>> > it's
>> > going a bit far.
>> >
>> > On Thu, Mar 10, 2016 at 5:25 PM, Mike Hommey  wrote:
>> >
>> >> On Thu, Mar 10, 2016 at 01:03:43PM -0500, Benjamin Smedberg wrote:
>> >> > This is notice of an intent to deprecate support within Firefox for
>> >> > the
>> >> > following old versions of MacOS: 10.6, 10.7, and 10.8
>> >> >
>> >> > The motivation for this change is that we have continued failures
>> >> > that
>> >> are
>> >> > specific to these old operating systems and don't have the resources
>> >> > on
>> >> > engineering teams to prioritize these bugs. Especially with the
>> >> deployment
>> >> > of e10s we're seeing intermittent and permanently failures on MacOS
>> >> > 10.6
>> >> > that we are not seeing elsewhere. We get very little testing of old
>> >> MacOS
>> >> > versions from our prerelease testers and cannot dedicate much paid
>> >> > staff
>> >> > testing support to these platforms. We also have an increasingly
>> >> fragile set
>> >> > of old hardware that supports automated tests on 10.6 and do not
>> >> > intend
>> >> to
>> >> > replace this.
>> >> >
>> >> > This will affect approximately 1.2% of our current release
>> >> > population.
>> >> Here
>> >> > are the specific breakdowns by OS version:
>> >> >
>> >> > 10.6
>> >> >   0.66%
>> >> > 10.7
>> >> >   0.38%
>> >> > 10.8
>> >> >   0.18%
>> >>
>> >> It's unfair to mention those populations by percentage of the global
>> >> Firefox population. What are those percentages relative to the number
>> >> of
>> >> OSX users? ISTR 10.6 represented something like 25% of the OSX users,
>> >> which is a totally different story (but maybe I'm mixing things with
>> >> Windows XP).
>> >>
>> >> Mike
>> >> ___
>> >> firefox-dev mailing list
>> >> firefox-...@mozilla.org
>> >> https://mail.mozilla.org/listinfo/firefox-dev
>> >>
>> >
>> >
>> > ___
>> > firefox-dev mailing list
>> > firefox-...@mozilla.org
>> > https://mail.mozilla.org/listinfo/firefox-dev
>> >
>> >
>>
>>
>> --
>> Tyler Downer
>> Project Manager, User Advocacy
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>


-- 
Tyler Downer
Project Manager, User Advocacy
___
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

[Mike Hommey]

On Fri, Mar 11, 2016 at 07:49:26AM +0800, Kyle Huey wrote:
> On Fri, Mar 11, 2016 at 2:03 AM, Benjamin Smedberg 
> wrote:
> 
> > This is notice of an intent to deprecate support within Firefox for the
> > following old versions of MacOS: 10.6, 10.7, and 10.8
> >
> > The motivation for this change is that we have continued failures that are
> > specific to these old operating systems and don't have the resources on
> > engineering teams to prioritize these bugs. Especially with the deployment
> > of e10s we're seeing intermittent and permanently failures on MacOS 10.6
> > that we are not seeing elsewhere. We get very little testing of old MacOS
> > versions from our prerelease testers and cannot dedicate much paid staff
> > testing support to these platforms. We also have an increasingly fragile
> > set of old hardware that supports automated tests on 10.6 and do not intend
> > to replace this.
> >
> > This will affect approximately 1.2% of our current release population.
> > Here are the specific breakdowns by OS version:
> > 10.6
> > 0.66%
> > 10.7
> > 0.38%
> > 10.8
> > 0.18%
> >
> > The final timeframe for this deprecation has not been finalized, but the
> > current proposal is to remove support in Firefox 46. We will try and update
> > existing users on old MacOS versions to the Firefox 45 ESR release stream,
> > so that they stay with security update support through the end of 2016.
> >
> > Because of the ESR update window, I would like to finalize this decision
> > by Monday. If you have questions or concerns about this plan, please reply
> > to the firefox-dev mailing list immediately. Jeff Griffiths will be working
> > with our communications team to coordinate more public communications such
> > as post to the Future of Firefox blog.
> >
> > --BDS
> >
> 
> Why can't we just not ship e10s to these users?  We have a number of other
> populations we're not shipping to, at least for now.

This is actually a sensible option.
A not-quite top-notch but up-to-date Firefox is still better than old
versions of Firefox or other browsers.

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

[Kyle Huey]

On Fri, Mar 11, 2016 at 2:03 AM, Benjamin Smedberg 
wrote:

> This is notice of an intent to deprecate support within Firefox for the
> following old versions of MacOS: 10.6, 10.7, and 10.8
>
> The motivation for this change is that we have continued failures that are
> specific to these old operating systems and don't have the resources on
> engineering teams to prioritize these bugs. Especially with the deployment
> of e10s we're seeing intermittent and permanently failures on MacOS 10.6
> that we are not seeing elsewhere. We get very little testing of old MacOS
> versions from our prerelease testers and cannot dedicate much paid staff
> testing support to these platforms. We also have an increasingly fragile
> set of old hardware that supports automated tests on 10.6 and do not intend
> to replace this.
>
> This will affect approximately 1.2% of our current release population.
> Here are the specific breakdowns by OS version:
> 10.6
> 0.66%
> 10.7
> 0.38%
> 10.8
> 0.18%
>
> The final timeframe for this deprecation has not been finalized, but the
> current proposal is to remove support in Firefox 46. We will try and update
> existing users on old MacOS versions to the Firefox 45 ESR release stream,
> so that they stay with security update support through the end of 2016.
>
> Because of the ESR update window, I would like to finalize this decision
> by Monday. If you have questions or concerns about this plan, please reply
> to the firefox-dev mailing list immediately. Jeff Griffiths will be working
> with our communications team to coordinate more public communications such
> as post to the Future of Firefox blog.
>
> --BDS
>

Why can't we just not ship e10s to these users?  We have a number of other
populations we're not shipping to, at least for now.

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

[Tyler Downer]

That brings up a point, if a user is on 10.8, gets moved to ESR 45, and
later moves to 10.11, will they be stuck on ESR still?

On Thu, Mar 10, 2016 at 4:01 PM, Tyler Downer  wrote:

> The other thing to note is many of those users can still update to 10.11,
> and I imagine that over the next year that number will continue to go down.
> This also provides a decent workaround that our support community can
> recommend in documentation and the forums.
>
> On Thu, Mar 10, 2016 at 3:50 PM, Ryan VanderMeulen <
> rvandermeu...@mozilla.com> wrote:
>
>> 25% is pretty close for 10.6-10.8 combined. However, the current proposal
>> includes security patches for nearly a year still (putting them on the
>> ESR45 train), so construing this as abandoning those users seems like it's
>> going a bit far.
>>
>> On Thu, Mar 10, 2016 at 5:25 PM, Mike Hommey  wrote:
>>
>>> On Thu, Mar 10, 2016 at 01:03:43PM -0500, Benjamin Smedberg wrote:
>>> > This is notice of an intent to deprecate support within Firefox for the
>>> > following old versions of MacOS: 10.6, 10.7, and 10.8
>>> >
>>> > The motivation for this change is that we have continued failures that
>>> are
>>> > specific to these old operating systems and don't have the resources on
>>> > engineering teams to prioritize these bugs. Especially with the
>>> deployment
>>> > of e10s we're seeing intermittent and permanently failures on MacOS
>>> 10.6
>>> > that we are not seeing elsewhere. We get very little testing of old
>>> MacOS
>>> > versions from our prerelease testers and cannot dedicate much paid
>>> staff
>>> > testing support to these platforms. We also have an increasingly
>>> fragile set
>>> > of old hardware that supports automated tests on 10.6 and do not
>>> intend to
>>> > replace this.
>>> >
>>> > This will affect approximately 1.2% of our current release population.
>>> Here
>>> > are the specific breakdowns by OS version:
>>> >
>>> > 10.6
>>> >   0.66%
>>> > 10.7
>>> >   0.38%
>>> > 10.8
>>> >   0.18%
>>>
>>> It's unfair to mention those populations by percentage of the global
>>> Firefox population. What are those percentages relative to the number of
>>> OSX users? ISTR 10.6 represented something like 25% of the OSX users,
>>> which is a totally different story (but maybe I'm mixing things with
>>> Windows XP).
>>>
>>> Mike
>>> ___
>>> firefox-dev mailing list
>>> firefox-...@mozilla.org
>>> https://mail.mozilla.org/listinfo/firefox-dev
>>>
>>
>>
>> ___
>> firefox-dev mailing list
>> firefox-...@mozilla.org
>> https://mail.mozilla.org/listinfo/firefox-dev
>>
>>
>
>
> --
> Tyler Downer
> Project Manager, User Advocacy
>



-- 
Tyler Downer
Project Manager, User Advocacy
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: navigator.clipboard

[Neil Deakin]

The linked document seems only concerned with one usecase of the 
clipboard, that of adding a 'copy to clipboard' type button to a page, 
but doesn't address any other cases, namely the more common case of 
copy/paste using the browser UI (edit menu, keyboard shortcuts), for 
which the existing event driven model is more suited.


I don't think that having two separate APIs for each usage is a good 
idea. I think you want to make use of the DataTransfer object in the new 
APIs as well. For example:

let c = new ClipboardData(...);
...
clipboard.copy(c)

Having an asynchronous promise-based way of retrieving data is needed 
though, but is needed for all clipboard usage, as well as for 
drag-and-drop which also uses DataTransfer. I'd suggest instead to just 
add some additional methods to DataTransfer for this. I filed a bug 
recently (https://bugzilla.mozilla.org/show_bug.cgi?id=1221562) about this.


As an aside, in IE5 one could do:
window.clipboardData.setData("text/plain", "Data");

So the proposed syntax has some precedent.
Neil

On 2016-03-10 3:00 PM, Hallvord Reiar Michaelsen Steen wrote:

People kindly pointed out to me that the plain-text forwarded message
had lost the link to Lucas's draft. Here it is:
https://docs.google.com/document/d/1QI5rKJSiYeD9ekP2NyCYJuOnivduC9-tqEOn-GsCGS4/edit#

On Thu, Mar 10, 2016 at 3:57 PM, Hallvord Reiar Michaelsen Steen
 wrote:

Hi dev-platform-people,
while editing the clipboard API spec [1] it's sometimes been suggested
to forget about the old slightly cranky API and start fresh. I haven't
had much response from implementors when such ideas came up on
public-webapps, but here's an interesting E-mail from Lucas Garron at
Google who has drafted a document that might turn into a spec for a
better clipboard API.

I've been allowed to circulate this and ask which developers at
Mozilla might want to be involved in giving feedback on and perhaps
eventually implement such a draft spec. See Lucas's E-mail and the
linked draft below.
-Hallvord

[1] https://w3c.github.io/clipboard-apis/


-- Forwarded message --
From: Lucas Garron 
Date: Wed, Mar 9, 2016 at 4:16 AM
Subject: navigator.clipboard
To: hst...@mozilla.com
Cc: Daniel Cheng 


Hello Hallvord,

I'm a security engineer from Chrome who was slightly involved in
bringing text copying to the open web in Chrome. (Daniel Cheng, CCed,
did most of the hard work.)  After introducing copying, we punted on
the topic of image formats, pasting, and clipboard listening, but it
has recently come up again.

At this point, I'm strongly interested in exploring the possibility of
"getting things right" by introducing a fresh clipboard API, which I'm
tentatively referring to as "navigator.clipboard" (although
window.clipboard would be fine, too ;-).

I know that it can be a common fallacy to start over on part of the
web platform, but document.execCommand() has a *lot* of baggage from
its designMode origins and it seems you yourself have wondered whether
browsers should consider something else.
We're seeing is a mounting desire to support more clipboard features
on the open web, and I think now is the time to consider a
straightforward-to-use API that is asynchronous:
- We want to transcode image formats for security, but this would
block a synchronous API.
- Paste will require a permission prompt in Chrome, which is much more
straightforward for Promise-based API.

I've started a very drafty proposal, mostly focused on historical
context and reasons to start fresh.

Do you have time and interest in collaborating to adapting the
clipboard API spec to a fresh clipboard API?

There are teams at Google with an active interest (e.g. Chrome Remote
Desktop, Google Docs) in bringing clipboard paste/listening to the
open web whom I'd like to bring in to lead an effort from the Google
side, but I wanted to ask you early in the process.

Thanks,
»Lucas


___
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

[Ryan VanderMeulen]

On 3/10/2016 6:38 PM, Nils Ohlmeier wrote:

Excuse my ignorance, but what means “deprecate support” exactly?

I’m only asking because of the opposing reply’s so far. I’m assuming it means 
we stop testing and building/releasing for these. Would it be a possible 
alternative to turn of the tests, but continue to build and release unsupported 
builds?
I know that this only prolongs it and doesn’t help with regards to the C++ 
problems, but would be interested in the counter arguments for such a “middle 
ground solution”.


Past experience suggests that things rapidly break when we aren't 
building/testing them in automation. I think the B2G folks can attest to 
that most-recently.


___
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 Mar 10, 2016, at 10:03, Benjamin Smedberg  wrote:
> 
> This is notice of an intent to deprecate support within Firefox for the 
> following old versions of MacOS: 10.6, 10.7, and 10.8

Excuse my ignorance, but what means “deprecate support” exactly?

I’m only asking because of the opposing reply’s so far. I’m assuming it means 
we stop testing and building/releasing for these. Would it be a possible 
alternative to turn of the tests, but continue to build and release unsupported 
builds?
I know that this only prolongs it and doesn’t help with regards to the C++ 
problems, but would be interested in the counter arguments for such a “middle 
ground solution”.

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

[Mike Hommey]

On Thu, Mar 10, 2016 at 05:20:41PM -0600, Syd Polk wrote:
> I do, however, think that supporting 10.6 is a heavy, heavy burden, as its 
> C++ compiler is truly ancient.

We build Firefox targetting 10.6 with a development version of clang 3.8
(that is, a clang build from a svn revision during the 3.8 development
cycle). What *is* ancient is its libstdc++.

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

[Syd Polk]

10.6 is the last version with Rosetta. Given how old the machines are that can 
run 10.6, and given how old 10.6 itself is, it is highly likely that 10.6 
customers still have PowerPC apps that they run and they cannot/will not 
upgrade.

Also, the perception of the Mac community in general is that 10.6 is the most 
stable release of OS X.

If you have old hardware (esp. if you have Power PC apps), there is very little 
reason to upgrade off of 10.6 until your hardware dies.

In the past, when these numbers were run, 10.6 was right on up there with the 
latest one or two OS X releases in Firefox usage, but 10.7 and 10.8 were almost 
gone.

I do, however, think that supporting 10.6 is a heavy, heavy burden, as its C++ 
compiler is truly ancient.

Just opinion, no recommendations here.

Syd Polk
sp...@mozilla.com
+1-512-905-9904
irc: sydpolk





> On Mar 10, 2016, at 17:17, Trevor Saunders  wrote:
> 
> On Thu, Mar 10, 2016 at 04:01:15PM -0700, Tyler Downer wrote:
>> The other thing to note is many of those users can still update to 10.11,
>> and I imagine that over the next year that number will continue to go down.
> 
> given they haven't upgraded from 10.6 - 10.8 why do you believe they are
> likely to in the future?
> 
> Trev
> 
>> This also provides a decent workaround that our support community can
>> recommend in documentation and the forums.
>> 
>> On Thu, Mar 10, 2016 at 3:50 PM, Ryan VanderMeulen <
>> rvandermeu...@mozilla.com> wrote:
>> 
>>> 25% is pretty close for 10.6-10.8 combined. However, the current proposal
>>> includes security patches for nearly a year still (putting them on the
>>> ESR45 train), so construing this as abandoning those users seems like it's
>>> going a bit far.
>>> 
>>> On Thu, Mar 10, 2016 at 5:25 PM, Mike Hommey  wrote:
>>> 
 On Thu, Mar 10, 2016 at 01:03:43PM -0500, Benjamin Smedberg wrote:
> This is notice of an intent to deprecate support within Firefox for the
> following old versions of MacOS: 10.6, 10.7, and 10.8
> 
> The motivation for this change is that we have continued failures that
 are
> specific to these old operating systems and don't have the resources on
> engineering teams to prioritize these bugs. Especially with the
 deployment
> of e10s we're seeing intermittent and permanently failures on MacOS 10.6
> that we are not seeing elsewhere. We get very little testing of old
 MacOS
> versions from our prerelease testers and cannot dedicate much paid staff
> testing support to these platforms. We also have an increasingly
 fragile set
> of old hardware that supports automated tests on 10.6 and do not intend
 to
> replace this.
> 
> This will affect approximately 1.2% of our current release population.
 Here
> are the specific breakdowns by OS version:
> 
> 10.6
>  0.66%
> 10.7
>  0.38%
> 10.8
>  0.18%
 
 It's unfair to mention those populations by percentage of the global
 Firefox population. What are those percentages relative to the number of
 OSX users? ISTR 10.6 represented something like 25% of the OSX users,
 which is a totally different story (but maybe I'm mixing things with
 Windows XP).
 
 Mike
 ___
 firefox-dev mailing list
 firefox-...@mozilla.org
 https://mail.mozilla.org/listinfo/firefox-dev
 
>>> 
>>> 
>>> ___
>>> firefox-dev mailing list
>>> firefox-...@mozilla.org
>>> https://mail.mozilla.org/listinfo/firefox-dev
>>> 
>>> 
>> 
>> 
>> -- 
>> Tyler Downer
>> Project Manager, User Advocacy
>> ___
>> 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

[Adam Roach]

On 3/10/16 5:17 PM, Trevor Saunders wrote:

On Thu, Mar 10, 2016 at 04:01:15PM -0700, Tyler Downer wrote:

The other thing to note is many of those users can still update to 10.11,
and I imagine that over the next year that number will continue to go down.

given they haven't upgraded from 10.6 - 10.8 why do you believe they are
likely to in the future?


Or even can? As I point out in my other message, a lot of the Intel Mac 
hardware cannot go past 10.6.


--
Adam Roach
Principal Platform Engineer
a...@mozilla.com
+1 650 903 0800 x863
___
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

[Trevor Saunders]

On Thu, Mar 10, 2016 at 04:01:15PM -0700, Tyler Downer wrote:
> The other thing to note is many of those users can still update to 10.11,
> and I imagine that over the next year that number will continue to go down.

given they haven't upgraded from 10.6 - 10.8 why do you believe they are
likely to in the future?

Trev

> This also provides a decent workaround that our support community can
> recommend in documentation and the forums.
> 
> On Thu, Mar 10, 2016 at 3:50 PM, Ryan VanderMeulen <
> rvandermeu...@mozilla.com> wrote:
> 
> > 25% is pretty close for 10.6-10.8 combined. However, the current proposal
> > includes security patches for nearly a year still (putting them on the
> > ESR45 train), so construing this as abandoning those users seems like it's
> > going a bit far.
> >
> > On Thu, Mar 10, 2016 at 5:25 PM, Mike Hommey  wrote:
> >
> >> On Thu, Mar 10, 2016 at 01:03:43PM -0500, Benjamin Smedberg wrote:
> >> > This is notice of an intent to deprecate support within Firefox for the
> >> > following old versions of MacOS: 10.6, 10.7, and 10.8
> >> >
> >> > The motivation for this change is that we have continued failures that
> >> are
> >> > specific to these old operating systems and don't have the resources on
> >> > engineering teams to prioritize these bugs. Especially with the
> >> deployment
> >> > of e10s we're seeing intermittent and permanently failures on MacOS 10.6
> >> > that we are not seeing elsewhere. We get very little testing of old
> >> MacOS
> >> > versions from our prerelease testers and cannot dedicate much paid staff
> >> > testing support to these platforms. We also have an increasingly
> >> fragile set
> >> > of old hardware that supports automated tests on 10.6 and do not intend
> >> to
> >> > replace this.
> >> >
> >> > This will affect approximately 1.2% of our current release population.
> >> Here
> >> > are the specific breakdowns by OS version:
> >> >
> >> > 10.6
> >> >   0.66%
> >> > 10.7
> >> >   0.38%
> >> > 10.8
> >> >   0.18%
> >>
> >> It's unfair to mention those populations by percentage of the global
> >> Firefox population. What are those percentages relative to the number of
> >> OSX users? ISTR 10.6 represented something like 25% of the OSX users,
> >> which is a totally different story (but maybe I'm mixing things with
> >> Windows XP).
> >>
> >> Mike
> >> ___
> >> firefox-dev mailing list
> >> firefox-...@mozilla.org
> >> https://mail.mozilla.org/listinfo/firefox-dev
> >>
> >
> >
> > ___
> > firefox-dev mailing list
> > firefox-...@mozilla.org
> > https://mail.mozilla.org/listinfo/firefox-dev
> >
> >
> 
> 
> -- 
> Tyler Downer
> Project Manager, User Advocacy
> ___
> 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: Are we in favour of implementing the client hints header?

[mnot]

Hey Jonas,

Please feel free to raise issues:
  https://github.com/httpwg/http-extensions/labels/client-hints

Cheers,
___
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

[Ryan VanderMeulen]

On 3/10/2016 5:47 PM, Masatoshi Kimura wrote:


Some fullscreen tests are enabled only on 10.6:
https://dxr.mozilla.org/mozilla-central/source/dom/tests/mochitest/chrome/chrome.ini#40

This proposal will virtually disable the fullscreen tests on OS X.



|skip-if = os != 'mac' ||  os_version == '10.6'| reads to me that 
they're running on OSX 10.10 and nowhere else. A cursory look at the 
Treeherder logs supports my interpretation of that condition.


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

[Tyler Downer]

The other thing to note is many of those users can still update to 10.11,
and I imagine that over the next year that number will continue to go down.
This also provides a decent workaround that our support community can
recommend in documentation and the forums.

On Thu, Mar 10, 2016 at 3:50 PM, Ryan VanderMeulen <
rvandermeu...@mozilla.com> wrote:

> 25% is pretty close for 10.6-10.8 combined. However, the current proposal
> includes security patches for nearly a year still (putting them on the
> ESR45 train), so construing this as abandoning those users seems like it's
> going a bit far.
>
> On Thu, Mar 10, 2016 at 5:25 PM, Mike Hommey  wrote:
>
>> On Thu, Mar 10, 2016 at 01:03:43PM -0500, Benjamin Smedberg wrote:
>> > This is notice of an intent to deprecate support within Firefox for the
>> > following old versions of MacOS: 10.6, 10.7, and 10.8
>> >
>> > The motivation for this change is that we have continued failures that
>> are
>> > specific to these old operating systems and don't have the resources on
>> > engineering teams to prioritize these bugs. Especially with the
>> deployment
>> > of e10s we're seeing intermittent and permanently failures on MacOS 10.6
>> > that we are not seeing elsewhere. We get very little testing of old
>> MacOS
>> > versions from our prerelease testers and cannot dedicate much paid staff
>> > testing support to these platforms. We also have an increasingly
>> fragile set
>> > of old hardware that supports automated tests on 10.6 and do not intend
>> to
>> > replace this.
>> >
>> > This will affect approximately 1.2% of our current release population.
>> Here
>> > are the specific breakdowns by OS version:
>> >
>> > 10.6
>> >   0.66%
>> > 10.7
>> >   0.38%
>> > 10.8
>> >   0.18%
>>
>> It's unfair to mention those populations by percentage of the global
>> Firefox population. What are those percentages relative to the number of
>> OSX users? ISTR 10.6 represented something like 25% of the OSX users,
>> which is a totally different story (but maybe I'm mixing things with
>> Windows XP).
>>
>> Mike
>> ___
>> firefox-dev mailing list
>> firefox-...@mozilla.org
>> https://mail.mozilla.org/listinfo/firefox-dev
>>
>
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>


-- 
Tyler Downer
Project Manager, User Advocacy
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Improving Platform quality

[William Lachance]

Hi Gabor! Thanks for starting this thread.

On 2016-03-10 5:07 AM, Gabor Krizsanits wrote:

While the other thread about fuzzing friendly Gecko is an interesting
option I would like to go back to the original topic, and start another
thread to collect other ideas too, that might help getting better on the
performance front. Here are some of my thoughts after spending some time
with the profiler and Talos tests in the past couple of weeks.

Probably most regression happens where we don't detect them because of the
lack of perf. test coverage. It should be easy and straightforward to add a
new Talos test (it isn't right now). There is an ongoing work on this I
think but don't know where is that work being tracked. We clearly need more
tests. A lot more. Especially if we want to ship features with huge impact
like multi-process Firefox or removing XUL. I don't think we have all the
metrics we need yet to make the best decisions.


Yes, this is now a lot easier now that we don't have to configure 
graphserver every time we add a unit test (Perfherder, as opposed to 
Graphserver, is smart enough to basically be able to handle anything new 
that people care to submit to it). In fact, :mconley just added a new 
test (tabpaint) last week, with no modifications necessary to Perfherder.


We (mainly meaning jmaher and myself, the Talos/Perfherder maintainers) 
haven't really emphasized/encouraging adding new tests in the past, as 
there was a feeling that we were having difficulty just staying on top 
of the existing tests that we had. Now that we have a better system for 
sheriffing regressions (as well as a system to seperate tests into 
different "buckets" so the burden of this can be shared amongst a larger 
group of people), it may well be time to consider adding new benchmarks.


Another thing to note is that new tests don't even need to be part of 
talos. We are now capable of accepting data from *any* job that is 
ingested by treeherder. For example, gbrown added a new Android-specific 
memory test as part of the mochitest-browser-chrome suite a couple weeks 
back:


https://gbrownmozilla.wordpress.com/2016/01/27/test_awsy_lite/


We do have some explanations about each Talos tests at
https://wiki.mozilla.org/Buildbot/Talos/Tests and I'm thankful for that but
some of the tests need more explanation, and some of them does not have
any. We could further improve that, it will save a lot of engineering time
(this wiki rocks by the way).


In the past, I've found needinfo'ing the test owner helpful for this 
sort of thing.



Add-ons. Last number I heard is that 40% of our users using some Add-ons,
we have access to these Add-ons code yet we don't have any performance
tests using them. It should be our responsibility to make sure if we
regress the user experience of our users with some of the most popular
Add-ons, we at least give a heads up to the authors and help them to
address the problem. I know resources are limited but maybe there are some
low hanging fruit here that would make a huge impact.


If I remember correctly, there were some efforts to run the standard set 
of Talos tests with addons enabled, but I don't think it was 
particularly successful. In general, I'm not crazy about creating too 
many variants of the existing tests will just lead to a firehose of 
information that will be difficult to manage.


I suspect creating a microbenchmark measuring some of the common 
internal operations an addon might want to do may be a better approach, 
though I could be wrong.


Will

___
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

[Ryan VanderMeulen]

25% is pretty close for 10.6-10.8 combined. However, the current proposal
includes security patches for nearly a year still (putting them on the
ESR45 train), so construing this as abandoning those users seems like it's
going a bit far.

On Thu, Mar 10, 2016 at 5:25 PM, Mike Hommey  wrote:

> On Thu, Mar 10, 2016 at 01:03:43PM -0500, Benjamin Smedberg wrote:
> > This is notice of an intent to deprecate support within Firefox for the
> > following old versions of MacOS: 10.6, 10.7, and 10.8
> >
> > The motivation for this change is that we have continued failures that
> are
> > specific to these old operating systems and don't have the resources on
> > engineering teams to prioritize these bugs. Especially with the
> deployment
> > of e10s we're seeing intermittent and permanently failures on MacOS 10.6
> > that we are not seeing elsewhere. We get very little testing of old MacOS
> > versions from our prerelease testers and cannot dedicate much paid staff
> > testing support to these platforms. We also have an increasingly fragile
> set
> > of old hardware that supports automated tests on 10.6 and do not intend
> to
> > replace this.
> >
> > This will affect approximately 1.2% of our current release population.
> Here
> > are the specific breakdowns by OS version:
> >
> > 10.6
> >   0.66%
> > 10.7
> >   0.38%
> > 10.8
> >   0.18%
>
> It's unfair to mention those populations by percentage of the global
> Firefox population. What are those percentages relative to the number of
> OSX users? ISTR 10.6 represented something like 25% of the OSX users,
> which is a totally different story (but maybe I'm mixing things with
> Windows XP).
>
> Mike
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
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

[Masatoshi Kimura]

On 2016/03/11 3:03, Benjamin Smedberg wrote:
> The motivation for this change is that we have continued failures that
> are specific to these old operating systems and don't have the resources
> on engineering teams to prioritize these bugs. Especially with the
> deployment of e10s we're seeing intermittent and permanently failures on
> MacOS 10.6 that we are not seeing elsewhere. We get very little testing
> of old MacOS versions from our prerelease testers and cannot dedicate
> much paid staff testing support to these platforms. We also have an
> increasingly fragile set of old hardware that supports automated tests
> on 10.6 and do not intend to replace this.

Some fullscreen tests are enabled only on 10.6:
https://dxr.mozilla.org/mozilla-central/source/dom/tests/mochitest/chrome/chrome.ini#40

This proposal will virtually disable the fullscreen tests on OS X.
___
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

[Nathan Froyd]

On Thu, Mar 10, 2016 at 5:25 PM, Mike Hommey  wrote:

> On Thu, Mar 10, 2016 at 01:03:43PM -0500, Benjamin Smedberg wrote:
> > This will affect approximately 1.2% of our current release population.
> Here
> > are the specific breakdowns by OS version:
> >
> > 10.6
> >   0.66%
> > 10.7
> >   0.38%
> > 10.8
> >   0.18%
>
> It's unfair to mention those populations by percentage of the global
> Firefox population. What are those percentages relative to the number of
> OSX users? ISTR 10.6 represented something like 25% of the OSX users,
> which is a totally different story (but maybe I'm mixing things with
> Windows XP).
>

I heard much the same thing from the media team when I suggested getting
rid of 10.6 support to make our C++ standard library situation easier.
CC'ing Anthony.

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

[Mike Hommey]

On Thu, Mar 10, 2016 at 01:03:43PM -0500, Benjamin Smedberg wrote:
> This is notice of an intent to deprecate support within Firefox for the
> following old versions of MacOS: 10.6, 10.7, and 10.8
> 
> The motivation for this change is that we have continued failures that are
> specific to these old operating systems and don't have the resources on
> engineering teams to prioritize these bugs. Especially with the deployment
> of e10s we're seeing intermittent and permanently failures on MacOS 10.6
> that we are not seeing elsewhere. We get very little testing of old MacOS
> versions from our prerelease testers and cannot dedicate much paid staff
> testing support to these platforms. We also have an increasingly fragile set
> of old hardware that supports automated tests on 10.6 and do not intend to
> replace this.
> 
> This will affect approximately 1.2% of our current release population. Here
> are the specific breakdowns by OS version:
> 
> 10.6
>   0.66%
> 10.7
>   0.38%
> 10.8
>   0.18%

It's unfair to mention those populations by percentage of the global
Firefox population. What are those percentages relative to the number of
OSX users? ISTR 10.6 represented something like 25% of the OSX users,
which is a totally different story (but maybe I'm mixing things with
Windows XP).

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

Re: Intent to switch to Visual Studio 2015

[Gregory Szorc]

On Thu, Mar 10, 2016 at 10:29 AM, Aaron Klotz  wrote:

> I'm looking forward to this!
>
> On 3/10/2016 9:14 AM, Gregory Szorc wrote:
>
>>
>> A host of new C++ features should be available after the switch. Although,
>> we may have to drop support for VS2013 before those can be fully realized.
>> I defer to others to determine when VS2013 will be dropped.
>>
>>
>>
> There's even more goodness in the pipe for Update 2. I know we need to
> move from VS2013 to VS2015 first, but do you anticipate a timely transition
> to Update 2 when it is released, or will that need to wait for a while?
>

One of the things we're doing as part of the transition to VS2015 is
changing how the toolchain files are installed in automation. There is now
a script that packages all relevant files (compiler executables, SDKs, etc)
into a standalone archive, which is used in automation. This means we don't
need changes to the Windows builders in automation: someone creates a new
archive with a new version of Visual Studio, uploads it to tooltool, and
updates the in-tree references to point to the new archive and automation
switches to the new Visual Studio version from that commit forward. In
other words, it becomes much easier to switch toolchains in automation.
This should decrease time to adopt new Visual Studio versions
significantly.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: W3C WebAppSec credentialmanagement API

[Ben Kelly]

Thanks for taking this on Alex!

I had some initial concerns with the API from a fetch/SW perspective, but
Mike seems open to addressing them:

  https://github.com/w3c/webappsec-credential-management/issues/11

I believe Matthew Noorenberghe had some concerns about the necessity of the
API given requestAutocomplete:


https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/7ouLjWzcjb0/s7aZHGnlAwAJ
  https://github.com/w3c/webappsec-credential-management/issues/2

We should probably come to some consensus there before moving forward.

Thanks again.

Ben

On Thu, Mar 10, 2016 at 1:56 PM, Axel Nennker  wrote:

> Summary: This API is enabling a website to request a user's credentials
> from a user agent, and helps the user agent to correctly store user
> credentials for future use. It helps the LoginManager to get rid of most of
> the heuristics.
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1156047
> Link to standard: https://w3c.github.io/webappsec-credential-management/
> Platform coverage: Desktop first, every platform that today has
> LoginManager
> Current code is here: https://github.com/AxelNennker/firefox_credentials/
> Estimated or target release: spec is still work in progress
> Preference behind which this will be implemented: not implemented yet
> DevTools bug:
> Suggested Additions: none, minimal viable API e.g. no password generation
> help by the UA. Federated Identity support is probably removed in the next
> version.
>
> Intend to ship in Chrome:
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/7ouLjWzcjb0
>
> Web designer / developer use-cases: examples are in the spec
> ___
> 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: navigator.clipboard

[Hallvord Reiar Michaelsen Steen]

People kindly pointed out to me that the plain-text forwarded message
had lost the link to Lucas's draft. Here it is:
https://docs.google.com/document/d/1QI5rKJSiYeD9ekP2NyCYJuOnivduC9-tqEOn-GsCGS4/edit#

On Thu, Mar 10, 2016 at 3:57 PM, Hallvord Reiar Michaelsen Steen
 wrote:
> Hi dev-platform-people,
> while editing the clipboard API spec [1] it's sometimes been suggested
> to forget about the old slightly cranky API and start fresh. I haven't
> had much response from implementors when such ideas came up on
> public-webapps, but here's an interesting E-mail from Lucas Garron at
> Google who has drafted a document that might turn into a spec for a
> better clipboard API.
>
> I've been allowed to circulate this and ask which developers at
> Mozilla might want to be involved in giving feedback on and perhaps
> eventually implement such a draft spec. See Lucas's E-mail and the
> linked draft below.
> -Hallvord
>
> [1] https://w3c.github.io/clipboard-apis/
>
>
> -- Forwarded message --
> From: Lucas Garron 
> Date: Wed, Mar 9, 2016 at 4:16 AM
> Subject: navigator.clipboard
> To: hst...@mozilla.com
> Cc: Daniel Cheng 
>
>
> Hello Hallvord,
>
> I'm a security engineer from Chrome who was slightly involved in
> bringing text copying to the open web in Chrome. (Daniel Cheng, CCed,
> did most of the hard work.)  After introducing copying, we punted on
> the topic of image formats, pasting, and clipboard listening, but it
> has recently come up again.
>
> At this point, I'm strongly interested in exploring the possibility of
> "getting things right" by introducing a fresh clipboard API, which I'm
> tentatively referring to as "navigator.clipboard" (although
> window.clipboard would be fine, too ;-).
>
> I know that it can be a common fallacy to start over on part of the
> web platform, but document.execCommand() has a *lot* of baggage from
> its designMode origins and it seems you yourself have wondered whether
> browsers should consider something else.
> We're seeing is a mounting desire to support more clipboard features
> on the open web, and I think now is the time to consider a
> straightforward-to-use API that is asynchronous:
> - We want to transcode image formats for security, but this would
> block a synchronous API.
> - Paste will require a permission prompt in Chrome, which is much more
> straightforward for Promise-based API.
>
> I've started a very drafty proposal, mostly focused on historical
> context and reasons to start fresh.
>
> Do you have time and interest in collaborating to adapting the
> clipboard API spec to a fresh clipboard API?
>
> There are teams at Google with an active interest (e.g. Chrome Remote
> Desktop, Google Docs) in bringing clipboard paste/listening to the
> open web whom I'd like to bring in to lead an effort from the Google
> side, but I wanted to ask you early in the process.
>
> Thanks,
> »Lucas
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Setting property on the element is no longer working on Firefox 45

[Kris Maglione]

On Thu, Mar 10, 2016 at 10:44:24AM -0800, Devan Shah wrote:

This happens in side extension only (works fine on web standalone), i will try 
to extract a simple reproducible scenario.

Is there any way to simulate a extension env on web?


If your problem is happening in an extension, then filing a bug 
and attaching a testcase add-on is your best bet.


If I had to guess based on what you've told us so far, I'd say 
your problem has something to do with X-ray security 
wrappers[1]. In general, properties that you add to X-ray 
wrappers aren't visible to code running in other globals. I.e., 
if you're accessing a web page from an SDK content script, your 
view of the DOM nodes are different from the view the web page 
sees. This also has implications for properties that you add to 
prototypes.


I don't know of any changes that would have significantly 
changed the behavior in 45 vs previous versions, though, so a 
testcase would be useful.


[1]: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/Xray_vision
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Setting property on the element is no longer working on Firefox 45

[Ted Mielczarek]

On Thu, Mar 10, 2016, at 01:23 PM, Devan Shah wrote:
> hello
> 
> When I set a custom property such as element.listofSomething = [] and
> then build the list and add it back to the same element. Then this
> element is passed to a function, now in that function I am no longer to
> access this property that I added to the function. 
> 
> Was there any sort of changes that would impact this?
> 
> Also if I make use of Element.prototype to set a custom variable and try
> to access it for an element it is not available any more. IS there
> something that I am missing. (note this is when inside a plugin)

FYI, I don't know what your particular bug is, but setting custom
properties on DOM elements is called "expandos", which might help you
file a more useful bug report:
https://developer.mozilla.org/en-US/docs/Glossary/Expando

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

Intent to implement: W3C WebAppSec credentialmanagement API

[Axel Nennker]

Summary: This API is enabling a website to request a user's credentials from a 
user agent, and helps the user agent to correctly store user credentials for 
future use. It helps the LoginManager to get rid of most of the heuristics.
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1156047
Link to standard: https://w3c.github.io/webappsec-credential-management/
Platform coverage: Desktop first, every platform that today has LoginManager
Current code is here: https://github.com/AxelNennker/firefox_credentials/
Estimated or target release: spec is still work in progress
Preference behind which this will be implemented: not implemented yet
DevTools bug: 
Suggested Additions: none, minimal viable API e.g. no password generation help 
by the UA. Federated Identity support is probably removed in the next version.

Intend to ship in Chrome: 
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/7ouLjWzcjb0

Web designer / developer use-cases: examples are in the spec
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Setting property on the element is no longer working on Firefox 45

[Josh Matthews]

On 2016-03-10 1:44 PM, Devan Shah wrote:

This happens in side extension only (works fine on web standalone), i will try 
to extract a simple reproducible scenario.

Is there any way to simulate a extension env on web?
Thanks



I do not believe so.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Setting property on the element is no longer working on Firefox 45

[Emma Humphries]

Devan,

I did a quick search and it looks like you'd be a new bugzilla contributor,
so thank you!

These have not been edited in a while, but if you're looking for guidance
on writing a bug

https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines
(nudge to the community, have a look at this and update it!)

The things that would be most helpful are

* reproduction steps
* isolated example

Thanks,

-- Emma Humphries, Bugmaster


On Thu, Mar 10, 2016 at 10:23 AM, Devan Shah  wrote:

> hello
>
> When I set a custom property such as element.listofSomething = [] and then
> build the list and add it back to the same element. Then this element is
> passed to a function, now in that function I am no longer to access this
> property that I added to the function.
>
> Was there any sort of changes that would impact this?
>
> Also if I make use of Element.prototype to set a custom variable and try
> to access it for an element it is not available any more. IS there
> something that I am missing. (note this is when inside a plugin)
>
> Thanks
> ___
> 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: Setting property on the element is no longer working on Firefox 45

[Devan Shah]

On Thursday, March 10, 2016 at 1:32:41 PM UTC-5, Josh Matthews wrote:
> Hi Devan! This is an interesting bug report, but it's lacking some 
> useful information to help triage it. Does this problem occur in a web 
> page, or extension, or some other environment? Can you create a minimal 
> example of the issue that anyone else could use to reproduce the problem 
> you're observing?
> 
> Cheers,
> Josh
> 
> On 2016-03-10 1:23 PM, Devan Shah wrote:
> > hello
> >
> > When I set a custom property such as element.listofSomething = [] and then 
> > build the list and add it back to the same element. Then this element is 
> > passed to a function, now in that function I am no longer to access this 
> > property that I added to the function.
> >
> > Was there any sort of changes that would impact this?
> >
> > Also if I make use of Element.prototype to set a custom variable and try to 
> > access it for an element it is not available any more. IS there something 
> > that I am missing. (note this is when inside a plugin)
> >
> > Thanks
> >

This happens in side extension only (works fine on web standalone), i will try 
to extract a simple reproducible scenario. 

Is there any way to simulate a extension env on web?
Thanks
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Setting property on the element is no longer working on Firefox 45

[Josh Matthews]

Hi Devan! This is an interesting bug report, but it's lacking some 
useful information to help triage it. Does this problem occur in a web 
page, or extension, or some other environment? Can you create a minimal 
example of the issue that anyone else could use to reproduce the problem 
you're observing?


Cheers,
Josh

On 2016-03-10 1:23 PM, Devan Shah wrote:

hello

When I set a custom property such as element.listofSomething = [] and then 
build the list and add it back to the same element. Then this element is passed 
to a function, now in that function I am no longer to access this property that 
I added to the function.

Was there any sort of changes that would impact this?

Also if I make use of Element.prototype to set a custom variable and try to 
access it for an element it is not available any more. IS there something that 
I am missing. (note this is when inside a plugin)

Thanks



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

Re: Intent to switch to Visual Studio 2015

[Aaron Klotz]

I'm looking forward to this!

On 3/10/2016 9:14 AM, Gregory Szorc wrote:


A host of new C++ features should be available after the switch. Although,
we may have to drop support for VS2013 before those can be fully realized.
I defer to others to determine when VS2013 will be dropped.




There's even more goodness in the pipe for Update 2. I know we need to 
move from VS2013 to VS2015 first, but do you anticipate a timely 
transition to Update 2 when it is released, or will that need to wait 
for a while?

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

Setting property on the element is no longer working on Firefox 45

[Devan Shah]

hello

When I set a custom property such as element.listofSomething = [] and then 
build the list and add it back to the same element. Then this element is passed 
to a function, now in that function I am no longer to access this property that 
I added to the function. 

Was there any sort of changes that would impact this?

Also if I make use of Element.prototype to set a custom variable and try to 
access it for an element it is not available any more. IS there something that 
I am missing. (note this is when inside a plugin)

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

Intent to deprecate: MacOS 10.6-10.8 support

[Benjamin Smedberg]

This is notice of an intent to deprecate support within Firefox for the 
following old versions of MacOS: 10.6, 10.7, and 10.8


The motivation for this change is that we have continued failures that 
are specific to these old operating systems and don't have the resources 
on engineering teams to prioritize these bugs. Especially with the 
deployment of e10s we're seeing intermittent and permanently failures on 
MacOS 10.6 that we are not seeing elsewhere. We get very little testing 
of old MacOS versions from our prerelease testers and cannot dedicate 
much paid staff testing support to these platforms. We also have an 
increasingly fragile set of old hardware that supports automated tests 
on 10.6 and do not intend to replace this.


This will affect approximately 1.2% of our current release population. 
Here are the specific breakdowns by OS version:


10.6
0.66%
10.7
0.38%
10.8
0.18%

The final timeframe for this deprecation has not been finalized, but the 
current proposal is to remove support in Firefox 46. We will try and 
update existing users on old MacOS versions to the Firefox 45 ESR 
release stream, so that they stay with security update support through 
the end of 2016.


Because of the ESR update window, I would like to finalize this decision 
by Monday. If you have questions or concerns about this plan, please 
reply to the firefox-dev mailing list immediately. Jeff Griffiths will 
be working with our communications team to coordinate more public 
communications such as post to the Future of Firefox blog.


--BDS


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

Intent to switch to Visual Studio 2015

[Gregory Szorc]

Visual Studio 2015 has been out for a while. Many people have put in work
to make Firefox build on it. The time has come to officially transition
release builds from Visual Studio 2013 to Visual Studio 2015.

This email serves as an intent to switch automation to Visual Studio 2015
Update 1 (latest stable release) as soon as possible, hopefully in the next
week or two.

A big driver for the switch is that builds with VS2015 are faster. PGO
builds in automation are 1+ hour faster than with VS2013 (see data in bug
1250797)! (Windows PGO builds are a long pole in the release process and
therefore prevent us from releasing faster - this is highly relevant during
chemspills.)

A host of new C++ features should be available after the switch. Although,
we may have to drop support for VS2013 before those can be fully realized.
I defer to others to determine when VS2013 will be dropped.

I feel like 95% of the transition work is completed. However, the following
Try pushes appear to have some new failures:

https://treeherder.mozilla.org/#/jobs?repo=try=d67e4a1f3735
https://treeherder.mozilla.org/#/jobs?repo=try=5c2a7b4e81d0 (PGO)

(Ignore SpiderMonkey failures - they are due to how the toolchain is being
hackily installed in those Try pushes.)

I could use your help triaging test failures and fixing fallout so we can
complete the transition to VS2015.

I'm very much a fan of perfect is the enemy of done and I feel temporary
workarounds (like e.g. disabling tests if there appears to be a minor
regression) may be warranted so we can give VS2015 extra time to bake on
Nightly. Otherwise, this may slip ~6 weeks until the next release. I feel
like we're too close to being able to transition to VS2015 to wait ~6 more
weeks.

Bug 1186060 is our master tracking bug for the VS2015 switch.

Thank you for everyone that has contributed to VS2015 fixes so far. Thank
you in advance for helping complete the transition.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Fwd: navigator.clipboard

[Hallvord Reiar Michaelsen Steen]

Hi dev-platform-people,
while editing the clipboard API spec [1] it's sometimes been suggested
to forget about the old slightly cranky API and start fresh. I haven't
had much response from implementors when such ideas came up on
public-webapps, but here's an interesting E-mail from Lucas Garron at
Google who has drafted a document that might turn into a spec for a
better clipboard API.

I've been allowed to circulate this and ask which developers at
Mozilla might want to be involved in giving feedback on and perhaps
eventually implement such a draft spec. See Lucas's E-mail and the
linked draft below.
-Hallvord

[1] https://w3c.github.io/clipboard-apis/


-- Forwarded message --
From: Lucas Garron 
Date: Wed, Mar 9, 2016 at 4:16 AM
Subject: navigator.clipboard
To: hst...@mozilla.com
Cc: Daniel Cheng 


Hello Hallvord,

I'm a security engineer from Chrome who was slightly involved in
bringing text copying to the open web in Chrome. (Daniel Cheng, CCed,
did most of the hard work.)  After introducing copying, we punted on
the topic of image formats, pasting, and clipboard listening, but it
has recently come up again.

At this point, I'm strongly interested in exploring the possibility of
"getting things right" by introducing a fresh clipboard API, which I'm
tentatively referring to as "navigator.clipboard" (although
window.clipboard would be fine, too ;-).

I know that it can be a common fallacy to start over on part of the
web platform, but document.execCommand() has a *lot* of baggage from
its designMode origins and it seems you yourself have wondered whether
browsers should consider something else.
We're seeing is a mounting desire to support more clipboard features
on the open web, and I think now is the time to consider a
straightforward-to-use API that is asynchronous:
- We want to transcode image formats for security, but this would
block a synchronous API.
- Paste will require a permission prompt in Chrome, which is much more
straightforward for Promise-based API.

I've started a very drafty proposal, mostly focused on historical
context and reasons to start fresh.

Do you have time and interest in collaborating to adapting the
clipboard API spec to a fresh clipboard API?

There are teams at Google with an active interest (e.g. Chrome Remote
Desktop, Google Docs) in bringing clipboard paste/listening to the
open web whom I'd like to bring in to lead an effort from the Google
side, but I wanted to ask you early in the process.

Thanks,
»Lucas
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Split Gecko in standalone fuzzing-friendly programs.

[Kurt Roeckx]

On 2016-03-09 22:17, Boris Zbarsky wrote:

On 3/9/16 3:47 PM, decoder...@googlemail.com wrote:

Actually no. I adapted our gtests in less than an hour.


Does this have to do with the set of things they're testing, or the
style the tests are written in?


I think the point is that some tests make it easy to set up fuzzing 
based on them.  I think what makes it easy is that it has a some input 
data that it puts thru some API.  For instance read some JS and either 
just parse it or even try to run it.  Or read some image file and decode 
it, maybe even calling the needed functions to display it.


Clearly everything were you get (untrusted) data from somewhere it 
should be relatively easy to set up fuzzing for it, but maybe it should 
start with writing a test suite that takes that input and does something 
with it, and probably tries to expose it to as much as possible things 
as the real application would.


So maybe the question isn't about having standalone programs, but more 
about a test suite tries to deals with input data like a program that 
uses the API would do.



Kurt

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

Re: Proposed W3C Charter: TV Control Working Group

[Jonas Sicking]

On Wed, Mar 9, 2016 at 11:53 PM, L. David Baron  wrote:
>   Although we've participated in the development of this work in the
>   community group, this is an area that we're becoming less involved
>   in.
>
>   We're also concerned about the general applicability of this work
>   to the Web.  Our own use of the subset of this API that we
>   implement has been restricted to privileged apps on Firefox OS,
>   and we're not aware of how it could fit in to the Web's security
>   model.

My personal opinion is that this API is still quite interesting for
TV-products. And that it fits the security model of the web. It's much
less privacy sensitive than getUserMedia or geolocation for example,
and so could use the same security model. The fact that we restricted
it to privileged apps I think was overly cautious.

However, I don't think that it's high enough priority that it's
something that we should invest in at this time.

So I would skip the second paragraph and instead add "at this time" to
the end of the first.

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

Re: Improving Platform quality

[Gabor Krizsanits]

While the other thread about fuzzing friendly Gecko is an interesting
option I would like to go back to the original topic, and start another
thread to collect other ideas too, that might help getting better on the
performance front. Here are some of my thoughts after spending some time
with the profiler and Talos tests in the past couple of weeks.

Probably most regression happens where we don't detect them because of the
lack of perf. test coverage. It should be easy and straightforward to add a
new Talos test (it isn't right now). There is an ongoing work on this I
think but don't know where is that work being tracked. We clearly need more
tests. A lot more. Especially if we want to ship features with huge impact
like multi-process Firefox or removing XUL. I don't think we have all the
metrics we need yet to make the best decisions.

We do have some explanations about each Talos tests at
https://wiki.mozilla.org/Buildbot/Talos/Tests and I'm thankful for that but
some of the tests need more explanation, and some of them does not have
any. We could further improve that, it will save a lot of engineering time
(this wiki rocks by the way).

The great thing about Talos tests that they can be profiled. What would be
even better if I could just compare two runs on the profiler level as
easily as I can compare the results now on threeherder compare. It would be
simpler to assign perf bugs, also less time consuming to fix them if I knew
instantly where that test used to spend the time and where is it spending
it right now. And most importantly where do I have to tune my module to
make the biggest impact on performance even if there is no regression.
(Backing out all the features that causing regression is not always the
option or the best way to gain back performance.)

I don't think the goal is the optimize Gecko. We need to optimize our end
products. So performance tests that go through the entire browser and
reproducing common user stories are the most important I think (we need
more). Gecko and Firefox is often deeply intertwined to a level that  joint
effort between Platform and Firefox team folks has the best chance to
tackle the more complex cases. I don't want to end up with a super fast
engine and slow browser because we put our focus on the wrong goal.

Add-ons. Last number I heard is that 40% of our users using some Add-ons,
we have access to these Add-ons code yet we don't have any performance
tests using them. It should be our responsibility to make sure if we
regress the user experience of our users with some of the most popular
Add-ons, we at least give a heads up to the authors and help them to
address the problem. I know resources are limited but maybe there are some
low hanging fruit here that would make a huge impact.

These are my two cents off the top of my head, I hope others have even
better ideas to share.

- Gabor

On Wed, Mar 9, 2016 at 12:09 AM, David Bryant  wrote:

> Platform Peeps,
>
> Improving release quality is one of the three fundamental goals Platform
> Engineering committed to this year. To this end, lmandel built a Bugzilla
> dashboard that allows us to track regressions found in any given release
> cycle. This dashboard is up on monitors in many of the offices and can also
> be found at: http://mozilla.github.io/releasehealth/
>
> While this metric might not be perfect, it does expose the number of
> newly-discovered regressions we would ship in a release. As of Monday*, we
> had *58* new regressions in Firefox 45 Beta -- this is the version that was
> released today. Of these bugs, 43 of them are unassigned**. Both of these
> things are unacceptable, and we will not continue to operate this way.
>
> Starting in release 46, we will *not* ship unless all new regressions are
> triaged and are either fixed or explicitly deferred by release management
> (working with Firefox engineering and Platform Engineering leads). We will
> hold a triage meeting every Monday at 2pm PT in the ReleaseCoordination
> Vidyo room, open to all of engineering, to stay on top of the overall
> regression list, and our first such meeting was yesterday. Bugs will be
> assigned by engineering managers and treated as release blockers.
>
> Engineering managers own the triage of their team's components. Please
> work with them and also let Johnny, Doug, or me know if you need help.
>
> All of us, together, are accountable for adopting this fundamental change
> in how we work. This is one of several changes that we’ll be making, so
> more to come.
>
>
> Thanks,
> David
>
>
> * Yes, I am aware that dougt, dveditz, and jst triaged on Monday, so this
> number may be slightly lower now.  Still it isn’t zarro.
>
> ** Yes, I am aware that some of the teams don’t always assign bugs, but I
> am asking everyone to start doing this. Unowned bugs will signal to us that
> they need help. Basically, we want the assignee field to be someone that is
> directly responsible for moving the bug to the 

Re: Proposed W3C Charter: TV Control Working Group

[Frederik Braun]

On 10.03.2016 08:53, L. David Baron wrote:
> On Tuesday 2016-03-01 09:32 +0800, L. David Baron wrote:
>> The W3C is proposing a charter for:
>>
>>   TV Control Working Group
>>   https://www.w3.org/2016/02/tvcontrol.html
>>   https://lists.w3.org/Archives/Public/public-new-work/2016Feb/0005.html
>>
>> Mozilla has the opportunity to send comments or objections through
>> Friday, March 18.
>>
>> Please reply to this thread if you think there's something we should
>> say as part of this charter review.
> 
> 
> So given that we've been pretty involved in the work in the
> community group that led to this working group, I think we probably
> should say something here.  I just talked to SC Chien and Joe Cheng
> about our involment and ran this plan (although not the text) past
> them.
> 
> 
> I think we should abstain from the review, but abstain with
> comments, saying something like:
> 
>   Although we've participated in the development of this work in the
>   community group, this is an area that we're becoming less involved
>   in.
> 
>   We're also concerned about the general applicability of this work
>   to the Web.  Our own use of the subset of this API that we
>   implement has been restricted to privileged apps on Firefox OS,
>   and we're not aware of how it could fit in to the Web's security
>   model.
> 
> Does this seem reasonable?

I have been involved in FxOS TV security things and I agree with this
assessment about compatibility with the web security model.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform