Re: Intent to deprecate: persistent permissions over HTTP
I have a slight twist in thinking to offer on the topic of persistent permissions.. part of this falls to the level of spitballing so forgive the imprecision: Restricting persistent permissions is essentially about cache poisoning attacks. The assumptions seem to be that a] https is not vulnerable b] every http transaction is as vulnerable as the last Those are imperfect (which, granted, is not necessarily a reason to not proceed - but read on for fun!). wrt A: We know that this assumption around https is a little sketchy due to the way the root store is commonly ...ummm.. localized. An enterprise user allows a new trust anchor for use with their company proxy, during which time they are by definition MITM'd by consent. I'm not especially worried about that transaction - such is the nature of the consent. But then they take that laptop home to a different context without that proxy. The cached information, in this case a persistent permission, remains. There is no reason to think the trust between those two environments should overlap. The HTTP cache has fundamentally the same problem (think about a ubiquitous resource like ga.js) as the persistent permission. wrt B: If a user on a home broadband connection conducts a transaction over plaintext she certainly is exposed to a MITM attack. But repeating that operation from the same location only adds small marginal risk (i.e. the risk of the path changing or the actors on that path changing - this can happen but often does not). OTOH if she moves to her neighbor's wifi or roams to 4g then its a whole new ballgame. The uri scheme isn't a good indicator of risk for each click. Daniel Stenberg has some code that tries to establish an internal what-network-am-i-on ID. Think of a more fully implemented version of it as a hash of your network interfaces and MACs, your router's MAC, etc.. Its currently just used as part of link-change-detection.. but it could make a pretty interesting part of a cache key for things we are worried about being poisoned - the result here would be scoping of persistent permissions to the topology that you accepted them on. On Fri, Mar 6, 2015 at 12:27 PM, Anne van Kesteren ann...@annevk.nl wrote: A large number of permissions we currently allow users to store persistently for a given origin. I suggest we stop offering that functionality when there's no lock in the address bar. This will make it harder for a network attacker to abuse these permissions. This would affect UX for: * Geolocation * Notification * Fullscreen * Pointer Lock * Popups If you are interested in demos of how these function today: * http://dontcallmedom.github.io/web-permissions-req/tests/geo-get.html * http://dontcallmedom.github.io/web-permissions-req/tests/notification.html * http://dontcallmedom.github.io/web-permissions-req/tests/fullscreen.html * http://dontcallmedom.github.io/web-permissions-req/tests/pointerlock.html * http://dontcallmedom.github.io/web-permissions-req/tests/popup.html Note that we have already implemented this for getUserMedia(). You can contrast the UX for these two links: * http://dontcallmedom.github.io/web-permissions-req/tests/gum-audiovideo.html * https://dontcallmedom.github.io/web-permissions-req/tests/gum-audiovideo.html This seems like a change we can make today that would be better for our users and nudge those that require persistence to do the right thing, without causing much harm. -- https://annevankesteren.nl/ ___ 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 not fix: Building with gcc-4.6 for Fx38+
On Wednesday, 11 March 2015 10:54:59 UTC, bo...@mozilla.com wrote: On Tuesday, March 10, 2015 at 5:06:31 PM UTC, Ehsan Akhgari wrote: Here's a push in case the bugs don't exist in certain builds: https://treeherder.mozilla.org/#/jobs?repo=tryrevision=044e896fc6fa I was looking at the log for a B2G Device Image build (I think it was the one for Nexus 5-L) a few days (less than a week) ago, and it was using gcc 4.8 for the target and gcc 4.6 for the host (assuming I was reading the logs correctly). I point this out because: (1) the device image build isn't in that try run, and (2) it's not clear to me that the compiler version checks check both the target and host compiler versions when cross-compiling That's a good point. I don't think we have any checks for the host compiler. I'll admit to knowing nothing about B2G Device Image builds, but I see that setting the default host compiler is in the instructions on the MDN B2G build instructions [1]. What are the reasons for this? The Firefox OS instructions [2] seem to suggest this is only needed for older versions of B2G. Are there automated Device Image builders that we will need to get updated? Do we need to inform partners, who might be using gcc-4.6? Am I right in thinking that B2G only currently uses up to Gecko 37? This may explain why we haven't seen a problem, but we might start seeing one since a merge a week ago. If we do a patch (for bug 1134487) is on mozilla-inbound and has been requested for uplift to beta. [1] https://developer.mozilla.org/en-US/Firefox_OS/Preparing_for_your_first_B2G_build [2] https://developer.mozilla.org/en-US/Firefox_OS/Firefox_OS_build_prerequisites This thread seems to have got de-railed somewhat. Could someone help me with my questions above? Thanks. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to not fix: Building with gcc-4.6 for Fx38+
On Wednesday, March 11, 2015 at 9:10:43 PM UTC+1, bobow...@gmail.com wrote: On Wednesday, 11 March 2015 10:54:59 UTC, bo...@mozilla.com wrote: On Tuesday, March 10, 2015 at 5:06:31 PM UTC, Ehsan Akhgari wrote: Here's a push in case the bugs don't exist in certain builds: https://treeherder.mozilla.org/#/jobs?repo=tryrevision=044e896fc6fa I was looking at the log for a B2G Device Image build (I think it was the one for Nexus 5-L) a few days (less than a week) ago, and it was using gcc 4.8 for the target and gcc 4.6 for the host (assuming I was reading the logs correctly). I point this out because: (1) the device image build isn't in that try run, and (2) it's not clear to me that the compiler version checks check both the target and host compiler versions when cross-compiling That's a good point. I don't think we have any checks for the host compiler. I'll admit to knowing nothing about B2G Device Image builds, but I see that setting the default host compiler is in the instructions on the MDN B2G build instructions [1]. What are the reasons for this? The Firefox OS instructions [2] seem to suggest this is only needed for older versions of B2G. Are there automated Device Image builders that we will need to get updated? Do we need to inform partners, who might be using gcc-4.6? Am I right in thinking that B2G only currently uses up to Gecko 37? This may explain why we haven't seen a problem, but we might start seeing one since a merge a week ago. If we do a patch (for bug 1134487) is on mozilla-inbound and has been requested for uplift to beta. [1] https://developer.mozilla.org/en-US/Firefox_OS/Preparing_for_your_first_B2G_build [2] https://developer.mozilla.org/en-US/Firefox_OS/Firefox_OS_build_prerequisites This thread seems to have got de-railed somewhat. Could someone help me with my questions above? Thanks. AFAIK, in B2G we are tied to the same host compiler version that our Android base platform needs. This is gcc-4.6 for ICS and JB devices (not really sure if KK/LL works with newer ones, but I'll bet they do). Of course, we could fix any incompatibilty and create our patches/forks so we can bump up our host compiler version, but moving away from Android base requierments is something that we should take with care. As Ryan stated earlier Gecko is being built with gcc-4.8 for all ICS/LL devices and gcc-4.7 for JB/KK (except Flatfish which is gcc-4.8 too), and I was going to start working on migrating to gcc-4.9 within the next coming days. When I finish, we could discuss if we should migrate _all_ B2G devices to the same toolchain version... but this is another story. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to not fix: Building with gcc-4.6 for Fx38+
On 2015-03-11 2:13 PM, Gregory Szorc wrote: On Wed, Mar 11, 2015 at 10:21 AM, Ehsan Akhgari ehsan.akhg...@gmail.com mailto:ehsan.akhg...@gmail.com wrote: On 2015-03-11 7:35 AM, Brian Smith wrote: Mike Hommey m...@glandium.org mailto:m...@glandium.org wrote: Brian Smith wrote: It is very inconvenient to have a minimum supported compiler version that we cannot even do test builds with using tryserver. Why this sudden requirement when our *current* minimum supported version is 4.6 and 4.6 is nowhere close to that on try. That is also true for older requirements we had for gcc. That is also true for clang on OSX, and that was also true for the short period we had MSVC 2012 as a minimum on Windows. I'm not saying this is an ideal situation, but I'd like to understand why gcc needs to suddenly be treated differently. The current situation is very inconvenient. To improve it, all compilers should be treated the same: Code that builds on mozilla-inbound/central/tryserver is good enough to land, as far as supported compiler versions are concerned. So, for example, if clang 3.7 is what is used on the builders, then clang 3.6 would be unsupported. And the same with GCC and MSVC. In my ideal world, instead of spending time debating what compilers we should use, we would stop relying on the system compiler, and build on all platforms with known good compilers of our choosing. That of course requires some build system work to get the compilers installed etc and unfortunately I don't think we have anyone lined up to do that work. But if we ever got there, we could have total control over what compilers are used to build our code, so we would not be affected by external factors such as distros' compiler choice. I would prefer the default build mode construct a chroot or Docker environment [that is the same environment Mozilla uses in automation] and we build in that. This build environment would be defined inside mozilla-central in such a way that it is reproducible over time. e.g. update your source repo to a commit from March 2015 and you automatically get the build environment that was used in March 2015. Another aspect of this switch is it gets us much closer to deterministic and reproducible builds. Docker will be a Linux specific solution though, right? Are there similar plans for other platforms? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to not fix: Building with gcc-4.6 for Fx38+
On Wed, Mar 11, 2015 at 10:21 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2015-03-11 7:35 AM, Brian Smith wrote: Mike Hommey m...@glandium.org wrote: Brian Smith wrote: It is very inconvenient to have a minimum supported compiler version that we cannot even do test builds with using tryserver. Why this sudden requirement when our *current* minimum supported version is 4.6 and 4.6 is nowhere close to that on try. That is also true for older requirements we had for gcc. That is also true for clang on OSX, and that was also true for the short period we had MSVC 2012 as a minimum on Windows. I'm not saying this is an ideal situation, but I'd like to understand why gcc needs to suddenly be treated differently. The current situation is very inconvenient. To improve it, all compilers should be treated the same: Code that builds on mozilla-inbound/central/tryserver is good enough to land, as far as supported compiler versions are concerned. So, for example, if clang 3.7 is what is used on the builders, then clang 3.6 would be unsupported. And the same with GCC and MSVC. In my ideal world, instead of spending time debating what compilers we should use, we would stop relying on the system compiler, and build on all platforms with known good compilers of our choosing. That of course requires some build system work to get the compilers installed etc and unfortunately I don't think we have anyone lined up to do that work. But if we ever got there, we could have total control over what compilers are used to build our code, so we would not be affected by external factors such as distros' compiler choice. I would prefer the default build mode construct a chroot or Docker environment [that is the same environment Mozilla uses in automation] and we build in that. This build environment would be defined inside mozilla-central in such a way that it is reproducible over time. e.g. update your source repo to a commit from March 2015 and you automatically get the build environment that was used in March 2015. Another aspect of this switch is it gets us much closer to deterministic and reproducible builds. This is achievable today. Bug 1133877 tracks an aspect of it. What I don't know is: 1) Who will write the code 2) Whether distros will use our official build environments. I suspect distros will have concerns about using our build environment (which is essentially a bare bones OS install) verbatim due to concerns like dependency hell and other things that distros worry about. Those reasons are valid. So I guess we trend towards supporting 2 build modes: Mozilla's official build environment via containers/chroots (preferred) or host native (for the people who insist on using it). Only host native exists today and it is a PITA. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to not fix: Building with gcc-4.6 for Fx38+
On 03/11/2015 07:13 PM, Gregory Szorc wrote: This build environment would be defined inside mozilla-central in such a way that it is reproducible over time. e.g. update your source repo to a commit from March 2015 and you automatically get the build environment that was used in March 2015. Another aspect of this switch is it gets us much closer to deterministic and reproducible builds. Am I reading docker and reproducible in the same statement? Do we intend to save one docker image for each modification of the script? How would we deal with updates of the distribution? When should we update our dependencies? Would we have to maintain a mirror for all versions of the the distribution? When I complain about the build system of FirefoxOS being damn crazy because you have to pull 106 repository over 108 that you only build once, this is even crazier than that. I hope we are never going to claim that the safest way of building Firefox is to download 8 GB of docker image. This is achievable today. Bug 1133877 tracks an aspect of it. Yes, we could also use less invasive solutions. Something which will not break users tools, while offering the option of a build environment which can be controlled, reproduced, verified (reproducibility wise), signed by Mozilla, shared between developers, and which works on Linux Mac ( Windows maybe one day …), such as what I started in Bug 1115107. What I don't know is: 2) Whether distros will use our official build environments. I think answer would be something less polite than no way!. On the other hand, this sounds like a simple way to lose a minor part of our user and the major part of our developers, if we are no longer going to support anything else. -- Nicolas B. Pierron ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozillabuild 2.0 ready for testing
On 09.03.2015 02:44, Ryan VanderMeulen wrote: For the past many months, I have been working on some major updates to the Mozillabuild package in order to make it more developer-friendly and easily-maintainable in the future. I am proud to say that at this time, it is ready for more widespread testing. The latest test build can be downloaded from the link below: http://people.mozilla.org/~rvandermeulen/MozillaBuildSetup2.0.0pre4.exe sha1sum: 9edb5c51bdb5f9a5d86baf5046967d8940654353 I have a batch script in my development folder that prepares some environment variables and finally calls C:\mozilla-build-test\start-shell-msvc2013.bat. The start-shell-msvc2013.bat script errors out immediately because start-shell.bat cannot be found in the current directory. In my opinion the script should not assume that it is started in C:\mozilla-build-test. I had to change CALL start-shell.bat to CALL %~dp0start-shell.bat to get the shell started. /Stefan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to not fix: Building with gcc-4.6 for Fx38+
On Wednesday, March 11, 2015 at 5:14:39 PM UTC, Ehsan Akhgari wrote: On 2015-03-11 8:34 AM, bo...@mozilla.com wrote: Given that we (and probably Chromium) would be unlikely to drop MSVC 2013 before our next ESR anyway That is not true. The compiler that we use to build ESR has nothing to do with the minimum compiler requirements on mozilla-central. I wasn't suggesting that they are tied in some way. I was just suggesting that there is a good chance that we won't have dropped MSVC 2013 by next March. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozillabuild 2.0 ready for testing
More context would be helpful. I personally run it out of c:\mozilla-build-test without issues. Are you using spaces in the path by chance? On Wed, Mar 11, 2015 at 3:21 PM, Chris Pearce cpea...@mozilla.com wrote: If I install this into a directory other than c:\mozilla-build I get an error dialog popup saying can't find c:\mozilla-build or somesuch. Maybe there's a path hardcoded somewhere? It's a bit of a footgun since the installer defaults to a non c:\mozilla-build install dir. Thanks very much for making bzexport work! cpearce. On 3/9/2015 2:44 PM, Ryan VanderMeulen wrote: For the past many months, I have been working on some major updates to the Mozillabuild package in order to make it more developer-friendly and easily-maintainable in the future. I am proud to say that at this time, it is ready for more widespread testing. The latest test build can be downloaded from the link below: http://people.mozilla.org/~rvandermeulen/MozillaBuildSetup2.0.0pre4.exe sha1sum: 9edb5c51bdb5f9a5d86baf5046967d8940654353 Release notes are available below. A few general notes: * It is strongly advised that you *NOT* install this over a previous 1.x install. Changes have been made to the directory structure and underlying packages that could result in unexpected results should you choose to do so. * As is always the case when updating Mozillabuild, you should clobber after installing. * Bugs that you come across can be filed in the mozilla.org::MozillaBuild component. My goal is to ship the final release in two weeks, so any feedback you can provide now would be welcome! Thanks, Ryan - SIGNIFICANT CHANGES * Added support for MSVC2015 and dropped support for MSVC 2013, WinSDK 8.1, and MSVC Express Edition. - MSVC Community Edition is now the recommended free compiler option * Added minTTY 1.1.3 and enabled it as the default console. - Windows cmd.exe can be used by default by removing the 1 from |SET USE_MINTTY=1| near the top of start-shell.bat * Overhauls to the start-msvc* batch scripts that improve consistency and simplify maintenance. - To launch a plain terminal with no MSVC path setting, use start-shell.bat (was start-shell-l10n.bat in previous releases) * Updated Mercurial to version 3.3.2 and switched to the native python version. - Allows extensions like bzexport that rely on previously-unavailable python components to work correctly. - Enables faster future updates in the event of serious bugs or security issues. - Enabled extensions: blackbox, color, histedit, mq, pager, progress, purge, rebase, share, transplant - See the Known Issues section for regressions from this change. * Updated python to version 2.7.9. - Included packages: pip 6.0.8, setuptools 14.0, virtualenv 12.0.7 OTHER UPDATES/ADDITIONS/REMOVALS * Removed SVN * Updated 7-zip to version 9.20 * Updated bundled CA certs to those from NSS 3.17.4 * Updated emacs to version 24.4 * Updated MSYS to version 1.0.18 and various components to the latest available for MSYS1 * Updated wget to version 1.16.1 KNOWN ISSUES * Changes in behavior due to using minTTY instead of Windows cmd.exe * Problems with python scripts that can't find an hg executable in the path (bug 1128586, bug 1131048) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to not fix: Building with gcc-4.6 for Fx38+
On 3/11/2015 1:13 PM, Gregory Szorc wrote: So I guess we trend towards supporting 2 build modes: Mozilla's official build environment via containers/chroots (preferred) or host native (for the people who insist on using it). Only host native exists today and it is a PITA. Using docker containers for most new contributor builds is likely to be a poorer experience for contributors than not doing so--most contributors are likely to want to run the built product on their local, host side of things rather than within the container, and if the runtime dependencies mismatch, the end result will be very painful. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozillabuild 2.0 ready for testing
Ah yes, I installed it to a patch with a space in it. Thanks! cpearce. On Thu, Mar 12, 2015 at 8:28 AM, Ryan VanderMeulen rvandermeu...@mozilla.com wrote: More context would be helpful. I personally run it out of c:\mozilla-build-test without issues. Are you using spaces in the path by chance? On Wed, Mar 11, 2015 at 3:21 PM, Chris Pearce cpea...@mozilla.com wrote: If I install this into a directory other than c:\mozilla-build I get an error dialog popup saying can't find c:\mozilla-build or somesuch. Maybe there's a path hardcoded somewhere? It's a bit of a footgun since the installer defaults to a non c:\mozilla-build install dir. Thanks very much for making bzexport work! cpearce. On 3/9/2015 2:44 PM, Ryan VanderMeulen wrote: For the past many months, I have been working on some major updates to the Mozillabuild package in order to make it more developer-friendly and easily-maintainable in the future. I am proud to say that at this time, it is ready for more widespread testing. The latest test build can be downloaded from the link below: http://people.mozilla.org/~rvandermeulen/MozillaBuildSetup2.0.0pre4.exe sha1sum: 9edb5c51bdb5f9a5d86baf5046967d8940654353 Release notes are available below. A few general notes: * It is strongly advised that you *NOT* install this over a previous 1.x install. Changes have been made to the directory structure and underlying packages that could result in unexpected results should you choose to do so. * As is always the case when updating Mozillabuild, you should clobber after installing. * Bugs that you come across can be filed in the mozilla.org: :MozillaBuild component. My goal is to ship the final release in two weeks, so any feedback you can provide now would be welcome! Thanks, Ryan - SIGNIFICANT CHANGES * Added support for MSVC2015 and dropped support for MSVC 2013, WinSDK 8.1, and MSVC Express Edition. - MSVC Community Edition is now the recommended free compiler option * Added minTTY 1.1.3 and enabled it as the default console. - Windows cmd.exe can be used by default by removing the 1 from |SET USE_MINTTY=1| near the top of start-shell.bat * Overhauls to the start-msvc* batch scripts that improve consistency and simplify maintenance. - To launch a plain terminal with no MSVC path setting, use start-shell.bat (was start-shell-l10n.bat in previous releases) * Updated Mercurial to version 3.3.2 and switched to the native python version. - Allows extensions like bzexport that rely on previously-unavailable python components to work correctly. - Enables faster future updates in the event of serious bugs or security issues. - Enabled extensions: blackbox, color, histedit, mq, pager, progress, purge, rebase, share, transplant - See the Known Issues section for regressions from this change. * Updated python to version 2.7.9. - Included packages: pip 6.0.8, setuptools 14.0, virtualenv 12.0.7 OTHER UPDATES/ADDITIONS/REMOVALS * Removed SVN * Updated 7-zip to version 9.20 * Updated bundled CA certs to those from NSS 3.17.4 * Updated emacs to version 24.4 * Updated MSYS to version 1.0.18 and various components to the latest available for MSYS1 * Updated wget to version 1.16.1 KNOWN ISSUES * Changes in behavior due to using minTTY instead of Windows cmd.exe * Problems with python scripts that can't find an hg executable in the path (bug 1128586, bug 1131048) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozillabuild 2.0 ready for testing
If I install this into a directory other than c:\mozilla-build I get an error dialog popup saying can't find c:\mozilla-build or somesuch. Maybe there's a path hardcoded somewhere? It's a bit of a footgun since the installer defaults to a non c:\mozilla-build install dir. Thanks very much for making bzexport work! cpearce. On 3/9/2015 2:44 PM, Ryan VanderMeulen wrote: For the past many months, I have been working on some major updates to the Mozillabuild package in order to make it more developer-friendly and easily-maintainable in the future. I am proud to say that at this time, it is ready for more widespread testing. The latest test build can be downloaded from the link below: http://people.mozilla.org/~rvandermeulen/MozillaBuildSetup2.0.0pre4.exe sha1sum: 9edb5c51bdb5f9a5d86baf5046967d8940654353 Release notes are available below. A few general notes: * It is strongly advised that you *NOT* install this over a previous 1.x install. Changes have been made to the directory structure and underlying packages that could result in unexpected results should you choose to do so. * As is always the case when updating Mozillabuild, you should clobber after installing. * Bugs that you come across can be filed in the mozilla.org::MozillaBuild component. My goal is to ship the final release in two weeks, so any feedback you can provide now would be welcome! Thanks, Ryan - SIGNIFICANT CHANGES * Added support for MSVC2015 and dropped support for MSVC 2013, WinSDK 8.1, and MSVC Express Edition. - MSVC Community Edition is now the recommended free compiler option * Added minTTY 1.1.3 and enabled it as the default console. - Windows cmd.exe can be used by default by removing the 1 from |SET USE_MINTTY=1| near the top of start-shell.bat * Overhauls to the start-msvc* batch scripts that improve consistency and simplify maintenance. - To launch a plain terminal with no MSVC path setting, use start-shell.bat (was start-shell-l10n.bat in previous releases) * Updated Mercurial to version 3.3.2 and switched to the native python version. - Allows extensions like bzexport that rely on previously-unavailable python components to work correctly. - Enables faster future updates in the event of serious bugs or security issues. - Enabled extensions: blackbox, color, histedit, mq, pager, progress, purge, rebase, share, transplant - See the Known Issues section for regressions from this change. * Updated python to version 2.7.9. - Included packages: pip 6.0.8, setuptools 14.0, virtualenv 12.0.7 OTHER UPDATES/ADDITIONS/REMOVALS * Removed SVN * Updated 7-zip to version 9.20 * Updated bundled CA certs to those from NSS 3.17.4 * Updated emacs to version 24.4 * Updated MSYS to version 1.0.18 and various components to the latest available for MSYS1 * Updated wget to version 1.16.1 KNOWN ISSUES * Changes in behavior due to using minTTY instead of Windows cmd.exe * Problems with python scripts that can't find an hg executable in the path (bug 1128586, bug 1131048) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Project Silk on Desktop
Hi all, Project Silk (http://www.masonchang.com/blog/2015/1/22/project-silk), which aligns rendering to vsync, will be landing over the next couple of weeks (bug 1071275). You should expect smoother animations and scrolling while browsing the web. It'll land in 4 parts, with the vsync compositor on OS X landing today. We'll start landing the vsync compositor on Windows a week or two from now, then the vsync refresh driver's on OSX and Windows a week or two after the vsync compositor. If you have any issues, please file bugs and make them block bug 1071275. Thanks to Jerry Shih, Benoit Girard, Kartikaya Gupta, Jeff Muizelaar, and Markus Stange for helping get this on desktop! Thanks, Mason ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: UI Workers
I've posted a followup of sorts to public-houdini: https://lists.w3.org/Archives/Public/public-houdini/2015Mar/0020.html There have been no replies, so I suspect I've said something terribly incomprehensible and/or wrong :-). Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to not fix: Building with gcc-4.6 for Fx38+
On Wed, Mar 11, 2015 at 2:30 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2015-03-11 2:13 PM, Gregory Szorc wrote: On Wed, Mar 11, 2015 at 10:21 AM, Ehsan Akhgari ehsan.akhg...@gmail.com mailto:ehsan.akhg...@gmail.com wrote: On 2015-03-11 7:35 AM, Brian Smith wrote: Mike Hommey m...@glandium.org mailto:m...@glandium.org wrote: Brian Smith wrote: It is very inconvenient to have a minimum supported compiler version that we cannot even do test builds with using tryserver. Why this sudden requirement when our *current* minimum supported version is 4.6 and 4.6 is nowhere close to that on try. That is also true for older requirements we had for gcc. That is also true for clang on OSX, and that was also true for the short period we had MSVC 2012 as a minimum on Windows. I'm not saying this is an ideal situation, but I'd like to understand why gcc needs to suddenly be treated differently. The current situation is very inconvenient. To improve it, all compilers should be treated the same: Code that builds on mozilla-inbound/central/tryserver is good enough to land, as far as supported compiler versions are concerned. So, for example, if clang 3.7 is what is used on the builders, then clang 3.6 would be unsupported. And the same with GCC and MSVC. In my ideal world, instead of spending time debating what compilers we should use, we would stop relying on the system compiler, and build on all platforms with known good compilers of our choosing. That of course requires some build system work to get the compilers installed etc and unfortunately I don't think we have anyone lined up to do that work. But if we ever got there, we could have total control over what compilers are used to build our code, so we would not be affected by external factors such as distros' compiler choice. I would prefer the default build mode construct a chroot or Docker environment [that is the same environment Mozilla uses in automation] and we build in that. This build environment would be defined inside mozilla-central in such a way that it is reproducible over time. e.g. update your source repo to a commit from March 2015 and you automatically get the build environment that was used in March 2015. Another aspect of this switch is it gets us much closer to deterministic and reproducible builds. Docker will be a Linux specific solution though, right? Are there similar plans for other platforms In terms of system parity, Linux is the most difficult. Every distro is different. Windows and OS X are more uniform. We get much more consistency and predictability on these platforms, especially Windows, where MozillaBuild is essentially a self-contained build environment (albeit with the OS-level isolation that Docker or LXC provides). I'm pretty sure we deal with more system incompatibilities issues from build system land with Linux than we do OS X and Windows combined. Supporting a well-defined and isolated build environment for Windows and Mac is more difficult. We even have licensing issues complicating matters. We do pretty well on both fronts today, even without the strong isolation provided by Docker/LXC. Without Docker, I think we'd be fine with continued use of MozillaBuild and something like a Mozilla-specific Homebrew/MacPorts install or something. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to not fix: Building with gcc-4.6 for Fx38+
On Tue, Mar 10, 2015 at 07:23:36PM -0700, Brian Smith wrote: bo...@mozilla.com wrote: In summary: Officially make gcc-4.7 our minimum supported version. Fx38 and 39 don't compile with 4.6 and none of the GNU/Linux package maintainers I have contacted have any major concerns over dropping it. I propose that either: (1) GCC 4.8 be made the minimum supported version immediately, or (2) The trychooser tool should be extended to make it possible to build with GCC 4.7 on any platforms where it is supported, and bootstrap.py be updated to install GCC 4.7 alongside the currently-installed compiler. I greatly prefer option (1). It is very inconvenient to have a minimum supported compiler version that we cannot even do test builds with using tryserver. Why this sudden requirement when our *current* minimum supported version is 4.6 and 4.6 is nowhere close to that on try. That is also true for older requirements we had for gcc. That is also true for clang on OSX, and that was also true for the short period we had MSVC 2012 as a minimum on Windows. I'm not saying this is an ideal situation, but I'd like to understand why gcc needs to suddenly be treated differently. Note that recent Ubuntu releases make it very easy to install GCC 4.8 but not so easy (AFAICT) to install other versions like GCC 4.7. I've contacted the package maintainers for Debian, Red Hat, openSUSE, SLES and Ubuntu and they either don't have a problem with dropping 4.6 or, at least, no more of a problem than the fact we've already dropped 4.4. Did any of them state a preference for not going to GCC 4.8? If so, what was the reasoning? At least for Debian, current stable can't build security updates with more than 4.7. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to not fix: Building with gcc-4.6 for Fx38+
Mike Hommey m...@glandium.org wrote: Brian Smith wrote: It is very inconvenient to have a minimum supported compiler version that we cannot even do test builds with using tryserver. Why this sudden requirement when our *current* minimum supported version is 4.6 and 4.6 is nowhere close to that on try. That is also true for older requirements we had for gcc. That is also true for clang on OSX, and that was also true for the short period we had MSVC 2012 as a minimum on Windows. I'm not saying this is an ideal situation, but I'd like to understand why gcc needs to suddenly be treated differently. The current situation is very inconvenient. To improve it, all compilers should be treated the same: Code that builds on mozilla-inbound/central/tryserver is good enough to land, as far as supported compiler versions are concerned. So, for example, if clang 3.7 is what is used on the builders, then clang 3.6 would be unsupported. And the same with GCC and MSVC. Further, it is best to upgrade compiler versions as fast as possible, so that we can make more use of newer C++ features. I contributed many patches in bug 1119072 so that MSVC 2015 can become the minimum MSVC version ASAP. The same should happen with GCC and clang so that we can write better code using newer C++ features ASAP. (This also requires replacing STLPort with a reasonable C++ standard library implementation on Android/B2G.) Did any of them state a preference for not going to GCC 4.8? If so, what was the reasoning? At least for Debian, current stable can't build security updates with more than 4.7. Isn't this a chicken and egg problem? If Firefox required GCC 4.9 then Debian would figure out a way to build security updates using GCC 4.9. It is easier for Debian to insist on GCC 4.7 so that's what Debian asks for. But, it is better to optimize for Mozilla developer efficiency than any Linux distros' efficiency. In particular, things like minimum compiler versions affect every Mozilla developer's efficiency, which affects the rate at which we can ship improvements to 100% of Mozilla's users. But, Linux-distro-packaged Firefox makes up less than 1% of the userbase. Note that I'm not saying Debian is unimportant. I'm saying that Mozilla should focus on what's best for developer productivity, and then assist Debian and others cope with whatever inconvenience that that strategy causes them. Cheers, Brian ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to not fix: Building with gcc-4.6 for Fx38+
On Tuesday, March 10, 2015 at 5:06:31 PM UTC, Ehsan Akhgari wrote: Here's a push in case the bugs don't exist in certain builds: https://treeherder.mozilla.org/#/jobs?repo=tryrevision=044e896fc6fa I was looking at the log for a B2G Device Image build (I think it was the one for Nexus 5-L) a few days (less than a week) ago, and it was using gcc 4.8 for the target and gcc 4.6 for the host (assuming I was reading the logs correctly). I point this out because: (1) the device image build isn't in that try run, and (2) it's not clear to me that the compiler version checks check both the target and host compiler versions when cross-compiling That's a good point. I don't think we have any checks for the host compiler. I'll admit to knowing nothing about B2G Device Image builds, but I see that setting the default host compiler is in the instructions on the MDN B2G build instructions [1]. What are the reasons for this? The Firefox OS instructions [2] seem to suggest this is only needed for older versions of B2G. Are there automated Device Image builders that we will need to get updated? Do we need to inform partners, who might be using gcc-4.6? Am I right in thinking that B2G only currently uses up to Gecko 37? This may explain why we haven't seen a problem, but we might start seeing one since a merge a week ago. If we do a patch (for bug 1134487) is on mozilla-inbound and has been requested for uplift to beta. [1] https://developer.mozilla.org/en-US/Firefox_OS/Preparing_for_your_first_B2G_build [2] https://developer.mozilla.org/en-US/Firefox_OS/Firefox_OS_build_prerequisites ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Off-main-thread compositing on Linux
Hi all, I am giving the heads up that Off-main-thread compositing (OMTC) will soon be enabled on Linux and that there are some expected talos regressions. In particular, a fairly big one in tp5o_scroll (see the compare-talos link below). http://perf.snarkfest.net/compare-talos/?oldRevs=56492f7244a9newRev=f8fbbd03280csubmit=true Enabling OMTC on Linux is very important because it is the foundation on top of which we will be able to use the optimizations and features that we have on the other platforms, such as tiled rendering, async scrolling and video playback, and also because e10s requires it. The benefits these features will bring outweigh the initial regressions, and I am confident we'll win back what we have to loose initially along with implementation of the followup projects. If you are interested in the details, we believe that the biggest causes of regressions are: 1) Synchronous communication with the compositor thread. This will be addressed by tiling which we already ship on mobile platforms and on Mac, and that will come to Windows and Linux. 2) Cairo's xrender backend also contributes to the regressions, but there is unfortunately not much we can do in the short term because getting rid of xrender has a fairly involved dependency chain (cf. replacing gtk2 by gtk3). e10s users will not be impacted since e10s enables OMTC automatically, so I assume a large part of the nightly population will not experience any difference. If you find issues related to omtc on linux, please file bugs against the Graphics: Layers component and cc me (:nical). Cheers, Nical ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to not fix: Building with gcc-4.6 for Fx38+
bo...@mozilla.com wrote: Also, from what I can tell of the C++ features that gcc-4.8 enables (from [1]), none of them are available until MSVC 2015. It seems likely that we'll be supporting MSVC 2013 until the next ESR, so I don't see that moving to 4.8 gives us any immediate benefits. [1] https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code ESR is also an incredibly wasteful drag on Mozilla development. When ESR was first proposed we agreed, as far as I understand, that we would NOT hold back improvements to the real Firefox for the sake of ESR. In fact, it is counterproductive to hold back changes like this for ESR's benefit because doing so makes it *harder* to backport changes to ESR. For example, imagine if you had updated the Chromium code after the next ESR branched, and then 12 months later a serious and hard-to-fix security bug in the old Chromium code was found*. It would be much less work to backport the patch is the minimum compiler version for ESR was as similar to the minimum compiler version for real Firefox. In the particular case of MSVC on Windows, it would be particularly good to make MSVC 2015 the minimum compiler version ASAP for this reason, assuming it will be possible at all. That's why I contributed all the patches in bug 1119072 elsewhere to facilitate that. Cheers, Brian * Of course, security researchers won't be looking at that old Chromium code because so few people use Firefox ESR that it isn't worth doing it. So, users of Firefox ESR will generally be less secure than users of the real Firefox. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to not fix: Building with gcc-4.6 for Fx38+
On Wednesday, March 11, 2015 at 11:53:11 AM UTC, Brian Smith wrote: bo...@mozilla.com wrote: Also, from what I can tell of the C++ features that gcc-4.8 enables (from [1]), none of them are available until MSVC 2015. It seems likely that we'll be supporting MSVC 2013 until the next ESR, so I don't see that moving to 4.8 gives us any immediate benefits. [1] https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code ESR is also an incredibly wasteful drag on Mozilla development. When ESR was first proposed we agreed, as far as I understand, that we would NOT hold back improvements to the real Firefox for the sake of ESR. In fact, it is counterproductive to hold back changes like this for ESR's benefit because doing so makes it *harder* to backport changes to ESR. For example, imagine if you had updated the Chromium code after the next ESR branched, and then 12 months later a serious and hard-to-fix security bug in the old Chromium code was found*. It would be much less work to backport the patch is the minimum compiler version for ESR was as similar to the minimum compiler version for real Firefox. Right, that's sort of the point I was trying (and probably failing) to make. Given that we (and probably Chromium) would be unlikely to drop MSVC 2013 before our next ESR anyway, then a complex security fix that used new c++ features is less likely. Unless the fix were in code only compiled with gcc, in which case we'd need to move to gcc-4.8 and look at alternatives for ESR. Moving to 4.8 now gives us no new features and causes at least some work for maintainers and from what I can tell, work to upgrade some of our build systems. If the policy is to not hold back improvements for the sake of ESR then the corollary to that should be that we don't push for changes in the ESR version just to protect it later. I'll be happy to help move us to 4.8 or later when we are looking to make MSVC 2015 the minimum. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to not fix: Building with gcc-4.6 for Fx38+
On Wednesday, March 11, 2015 at 8:40:46 AM UTC, Mike Hommey wrote: On Tue, Mar 10, 2015 at 07:23:36PM -0700, Brian Smith wrote: bo...@mozilla.com wrote: In summary: Officially make gcc-4.7 our minimum supported version. Fx38 and 39 don't compile with 4.6 and none of the GNU/Linux package maintainers I have contacted have any major concerns over dropping it. I propose that either: (1) GCC 4.8 be made the minimum supported version immediately, or *snip* I've contacted the package maintainers for Debian, Red Hat, openSUSE, SLES and Ubuntu and they either don't have a problem with dropping 4.6 or, at least, no more of a problem than the fact we've already dropped 4.4. Did any of them state a preference for not going to GCC 4.8? If so, what was the reasoning? At least for Debian, current stable can't build security updates with more than 4.7. In addition, as I understand it: * openSUSE still has supported versions with gcc-4.7 * SLES (on older versions without 4.6 or 4.7) use a special stack of packages to build Firefox which includes gcc-4.7 * Ubuntu 12.04 LTS has 4.6, but are happy to build with a later version as long as there are no runtime issues * Older versions of RHEL are still on gcc-4.4, so they are already going to have to do something for Fx37 anyway and moving to 4.7 instead of 4.6 would probably not cause too much extra pain. I don't know how much more work moving to gcc-4.8 would cause, but it would certainly be some. Also, from what I can tell of the C++ features that gcc-4.8 enables (from [1]), none of them are available until MSVC 2015. It seems likely that we'll be supporting MSVC 2013 until the next ESR, so I don't see that moving to 4.8 gives us any immediate benefits. [1] https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to not fix: Building with gcc-4.6 for Fx38+
Ryan VanderMeulen rya...@gmail.com wrote: (2) The trychooser tool should be extended to make it possible to build with GCC 4.7 on any platforms where it is supported, and bootstrap.py be updated to install GCC 4.7 alongside the currently-installed compiler. All Android and B2G JB/KK emulator builds are on GCC 4.7. Linux Desktop and B2G ICS/L emulator builds are GCC 4.8. All of the aforementioned are available on Trychooser. Thanks for sharing that. For the patches that I contribute to Gecko, that actually works out OK, because it seems like all my code is built on all those platforms. I The overall issue of wasting time supporting relatively unimportant configurations, which aren't checked during tryserver/inbound/central builds still applies, though. Cheers, Brian ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to not fix: Building with gcc-4.6 for Fx38+
On 3/11/15 2:56 PM, Juan Gómez wrote: AFAIK, in B2G we are tied to the same host compiler version that our Android base platform needs. This is gcc-4.6 for ICS and JB devices (not really sure if KK/LL works with newer ones, but I'll bet they do). Of course, we could fix any incompatibilty and create our patches/forks so we can bump up our host compiler version, but moving away from Android base requierments is something that we should take with care. How long do we need to continue building B2G trunk for ICS and JB? Do we have partner commitments to ship future releases from B2G trunk on ICS or JB devices? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to not fix: Building with gcc-4.6 for Fx38+
On 2015-03-11 8:36 PM, Gregory Szorc wrote: On Wed, Mar 11, 2015 at 2:30 PM, Ehsan Akhgari ehsan.akhg...@gmail.com mailto:ehsan.akhg...@gmail.com wrote: On 2015-03-11 2:13 PM, Gregory Szorc wrote: On Wed, Mar 11, 2015 at 10:21 AM, Ehsan Akhgari ehsan.akhg...@gmail.com mailto:ehsan.akhg...@gmail.com mailto:ehsan.akhgari@gmail.__com mailto:ehsan.akhg...@gmail.com wrote: On 2015-03-11 7:35 AM, Brian Smith wrote: Mike Hommey m...@glandium.org mailto:m...@glandium.org mailto:m...@glandium.org mailto:m...@glandium.org wrote: Brian Smith wrote: It is very inconvenient to have a minimum supported compiler version that we cannot even do test builds with using tryserver. Why this sudden requirement when our *current* minimum supported version is 4.6 and 4.6 is nowhere close to that on try. That is also true for older requirements we had for gcc. That is also true for clang on OSX, and that was also true for the short period we had MSVC 2012 as a minimum on Windows. I'm not saying this is an ideal situation, but I'd like to understand why gcc needs to suddenly be treated differently. The current situation is very inconvenient. To improve it, all compilers should be treated the same: Code that builds on mozilla-inbound/central/__tryserver is good enough to land, as far as supported compiler versions are concerned. So, for example, if clang 3.7 is what is used on the builders, then clang 3.6 would be unsupported. And the same with GCC and MSVC. In my ideal world, instead of spending time debating what compilers we should use, we would stop relying on the system compiler, and build on all platforms with known good compilers of our choosing. That of course requires some build system work to get the compilers installed etc and unfortunately I don't think we have anyone lined up to do that work. But if we ever got there, we could have total control over what compilers are used to build our code, so we would not be affected by external factors such as distros' compiler choice. I would prefer the default build mode construct a chroot or Docker environment [that is the same environment Mozilla uses in automation] and we build in that. This build environment would be defined inside mozilla-central in such a way that it is reproducible over time. e.g. update your source repo to a commit from March 2015 and you automatically get the build environment that was used in March 2015. Another aspect of this switch is it gets us much closer to deterministic and reproducible builds. Docker will be a Linux specific solution though, right? Are there similar plans for other platforms In terms of system parity, Linux is the most difficult. Every distro is different. Windows and OS X are more uniform. We get much more consistency and predictability on these platforms, especially Windows, where MozillaBuild is essentially a self-contained build environment (albeit with the OS-level isolation that Docker or LXC provides). I'm pretty sure we deal with more system incompatibilities issues from build system land with Linux than we do OS X and Windows combined. Supporting a well-defined and isolated build environment for Windows and Mac is more difficult. We even have licensing issues complicating matters. We do pretty well on both fronts today, even without the strong isolation provided by Docker/LXC. Without Docker, I think we'd be fine with continued use of MozillaBuild and something like a Mozilla-specific Homebrew/MacPorts install or something. Hmm, why not do something much simpler then, which is downloading a prebuilt zip file that contains the toolchain? The toolchains on Mac and Linux are redistributable, and for Windows we can redistribute a little python script that creates the toolchain from a Visual Studio Commmunity Edition installation. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to not fix: Building with gcc-4.6 for Fx38+
On 2015-03-11 6:05 PM, Chris Peterson wrote: On 3/11/15 2:56 PM, Juan Gómez wrote: AFAIK, in B2G we are tied to the same host compiler version that our Android base platform needs. This is gcc-4.6 for ICS and JB devices (not really sure if KK/LL works with newer ones, but I'll bet they do). Of course, we could fix any incompatibilty and create our patches/forks so we can bump up our host compiler version, but moving away from Android base requierments is something that we should take with care. How long do we need to continue building B2G trunk for ICS and JB? Do we have partner commitments to ship future releases from B2G trunk on ICS or JB devices? The emulator tests currently only run on ICS. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
