Re: Proposed W3C Charter: TV Control Working Group
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
Re: Improving Platform quality
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 next state. That might
Re: Proposed W3C Charter: TV Control Working Group
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: Split Gecko in standalone fuzzing-friendly programs.
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
Fwd: navigator.clipboard
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
Intent to switch to Visual Studio 2015
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&revision=d67e4a1f3735 https://treeherder.mozilla.org/#/jobs?repo=try&revision=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
Intent to deprecate: MacOS 10.6-10.8 support
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
Setting property on the element is no longer working on Firefox 45
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
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
Re: Setting property on the element is no longer working on Firefox 45
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: Setting property on the element is no longer working on Firefox 45
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
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
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
Intent to implement: W3C WebAppSec credentialmanagement API
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
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
Re: Setting property on the element is no longer working on Firefox 45
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: navigator.clipboard
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 switch to Visual Studio 2015
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
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: Intent to deprecate: MacOS 10.6-10.8 support
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 deprecate: MacOS 10.6-10.8 support
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
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
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: Improving Platform quality
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
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: Intent to deprecate: MacOS 10.6-10.8 support
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: Are we in favour of implementing the client hints header?
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
On 3/10/16 4:50 PM, Ryan VanderMeulen 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. I'm not sure the difference between "abandoning" and "irreversibly locking into being abandoned in ~1 year" is all that great. After initial drop-off, these versions have a pretty stable tail on them. http://lowendmac.com/2015/the-rise-and-fall-of-mac-os-x-versions-2009-to-2015/ OS X 10.7, in particular, was the first release to leave behind the Core Duo and Core Solo Intel hardware, which is still pretty capable and (apparently) still used by some sizable portion of the Mac community [1]. You'll notice, for example, that 10.6 has many more users than 10.7 or 10.8 does; and, in fact, appears to still account for 1 out of every 10 Mac users. To be clear: these users _cannot_ upgrade to 10.9 or later. It simply won't install. To put this in perspective: we continue to support XP, some 9 years after after the January 2007 release date of its successor. OS X 10.9 didn't come out until October of 2013, which is only two and a half years ago. [1] Full disclosure: I have and continue to use such hardware personally. -- 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
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: Intent to deprecate: MacOS 10.6-10.8 support
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
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
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
> 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
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: navigator.clipboard
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
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: Intent to deprecate: MacOS 10.6-10.8 support
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
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
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
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 implement: W3C WebAppSec credentialmanagement API
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: Are we in favour of implementing the client hints header?
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