Re: Disabling C++ tests by default?
On Thu, Oct 01, 2015 at 10:10:39PM -0700, Gregory Szorc wrote: > Currently, the Firefox build system builds C++ tests by default. This adds > extra time to builds for something that a significant chunk of developers > don't care about because they don't run them. > > An easy way to get faster builds is to disable C++ tests by default > (requiring a mozconfig entry to enable them - which would be enabled in > automation, of course). A more involved solution is to build them on > demand, when tests are executed (unless a build option says to build them > like today). > > I was curious if Gecko developers (the audience I perceive that cares about > them the most) would be generally opposed to disabling building C++ tests > by default. If not, we can go with an easy solution (and require people who > care to add a mozconfig entry). If so, we go with the harder solution. > > Is disabling building C++ tests by default a reasonable change? I don't think it is worth the effort. Specifically, we're not really equiped to actually do it currently, and all in all, it's not taking that much of the build time relative to all the other stuff. The one C++ test that has a significant build time impact is gtest, and we're already skipping it. I'm more interested in growing the faster-make backend to deal with C++ compilation in a sane way than working around the recursive-make deficiencies like this. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Disabling C++ tests by default?
How much time does it save? - Kyle On Thu, Oct 1, 2015 at 10:10 PM, Gregory Szorc wrote: > Currently, the Firefox build system builds C++ tests by default. This adds > extra time to builds for something that a significant chunk of developers > don't care about because they don't run them. > > An easy way to get faster builds is to disable C++ tests by default > (requiring a mozconfig entry to enable them - which would be enabled in > automation, of course). A more involved solution is to build them on > demand, when tests are executed (unless a build option says to build them > like today). > > I was curious if Gecko developers (the audience I perceive that cares about > them the most) would be generally opposed to disabling building C++ tests > by default. If not, we can go with an easy solution (and require people who > care to add a mozconfig entry). If so, we go with the harder solution. > > Is disabling building C++ tests by default a reasonable change? > ___ > 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
Disabling C++ tests by default?
Currently, the Firefox build system builds C++ tests by default. This adds extra time to builds for something that a significant chunk of developers don't care about because they don't run them. An easy way to get faster builds is to disable C++ tests by default (requiring a mozconfig entry to enable them - which would be enabled in automation, of course). A more involved solution is to build them on demand, when tests are executed (unless a build option says to build them like today). I was curious if Gecko developers (the audience I perceive that cares about them the most) would be generally opposed to disabling building C++ tests by default. If not, we can go with an easy solution (and require people who care to add a mozconfig entry). If so, we go with the harder solution. Is disabling building C++ tests by default a reasonable change? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: dialog=1 for window.open from content
On 2015-10-01 4:34 PM, Mike Conley wrote: Hello dev-platform, I'm currently working on bug 1095236 - that's an e10s bug for us failing to open any windows if the features string includes dialog=1 (or dialog=yes). According to [1], setting dialog=1 makes a popup window that removes the min/max/restore buttons, and no "command" menu (the icon usually appearing in the top left which opens the Restore, Move, Size, etc options). Note that this is only really apparent on Windows, where we default to having such buttons on popups. Also according to [1], Gecko is the only web engine to support that feature. Before I go whole-hog trying to fix bug 1095236, I'm curious to know if we really want to continue supporting dialog=1 from content, or if it's safe to just ignore that feature like the other browser engines (which I think would be the fastest path towards fixing bug 1095236). Are there any really good arguments to keep supporting it? A good argument, no. But these things can end up having a web compat impact. I personally think that the risk of web compat is not that high here but if we want to be sure, we can add a use counter for the feature and measure how much it's used in the release population, and decide based on that. Now that we have support for use counters, we don't need to guess any more. :-) Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Building js/xul/css from Firefox faster
Hi, I recently landed a new build backend that, if you opt-in to running it, will make your non-C++ changes to Firefox more readily available in local builds. After you built Firefox normally once, and assuming you only changed non-C++ code, you can now use the following command for a faster incremental build: ./mach build faster Now, since this is fresh out of the oven, there are a few things to know: - it doesn't handle removing files - it doesn't handle files that would end up outside of dist/bin - it doesn't handle a few things like the files from the default profile - it currently only works for desktop Firefox Obviously, this is not an end state, so things will improve in the future, but it should work well enough for most day-to-day work for desktop Firefox, thus this message. On my machine, `mach build faster` completes in about 4 seconds for an incremental build. This should get even faster very soon. Additionally, while requiring some manual steps (which bug 1207888 and bug 1207890 will help with), it is also possible to use this to build desktop Firefox without actually building any C++. Here is how that goes: - Run `./mach configure` with a mozconfig containing: ac_add_options --disable-compile-environment - Download and unpack a nightly - Use `./mach python toolkit/mozapps/installer/unpack.py `, where is the nightly's firefox/ directory. - Move that fully unpacked nightly to $objdir/dist/bin (for mac, that involves more fiddling, because dist/bin is a somewhat flattened version of the .app directory) - Ensure the files in $objdir/dist/bin are older than the source files. - Run `./mach build faster`. - On mac, you will need to run something like (untested) ./mach build browser/app/repackage After that $objdir/dist/bin should contain a bastardized Firefox, with xul, js, etc. coming from the source tree, and the remainder still being there from the original nightly. `mach run` should work with that. Cheers, Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: dialog=1 for window.open from content
Mike Conley wrote: > Are there any really good arguments to keep supporting it? I don't know how much data we have for dialog=1, but we'll end up needing to be able to do this for for showModalDialog (see bug 981796 and bug 1137025). -- Blake Kaplan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Content sniffing: seeking reliable protection of a text HTTP resource
Hello. This message asks for opinions and suggestions how to make Mozilla products understand «Content-Type» of a Web resource exactly as specified in HTTP(s) headers. Content sniffing in browsers is a compromise between standards and interoperability with “poor” Web sites. It creates vulnerabilities and, generally, breaks compatibility with (original) HTTP/1.1. In some cases it conceals protocol data from such end user’s tools as Ctrl-I (information on page). See http://www.superstructure.info/browser/compromised/toxic-sniffing.html for some generally less known information about it. I have particular concerns about two scenarios. First is “media type (a.k.a. MIME) sniffing”, when browser overrides media type/subtype. This is implemented in toolkit/components/mediasniffer/nsMediaSniffer.cpp component (and possibly others, don’t know). There is a proposal https://bugzilla.mozilla.org/show_bug.cgi?id=471020 to make behaviour of Firefox compatible with MS Internet Explorer and https://mimesniff.spec.whatwg.org/#supplied-mime-type-detection-algorithm , using «X-Content-Type-Options: nosniff» to switch the sniffing off. Second scenario is a less known “UTF sniffing”, applicable only to text media types. Browser respects the type proper, but overrides «charset=» label with own guesses. This is implemented in netwerk/base/nsUnicharStreamLoader.cpp ; such implementation is based on HTML5 encoding sniffing that isn’t applicable (reasonably) to text/plain. In the case of text/plain it leads to bugs. Simple test cases are available at http://course.irccity.ru/ya-yu-9-amp.txt (toxic UTF-16 “BOM”) and http://course.irccity.ru/p-guillemet-yi-ya.txt (toxic UTF-8 “BOM”). It poses less immediate security risk, but still can cause data corruption whenever arbitatry data are allowed into (beginning of) text/plain documents. The toxic UTF sniffing was observer in Firefox, MSIE, Google Chrome, and Safari and doesn’t seemingly correlate with «X-Content-Type-Options» mentioned above. Possible approaches to the toxic UTF sniffing include: • Just fix it (certainly would cause backlash from people eager to burn anything except UTF-8). • Something along the lines of the no-sniff flag. • Make a new Firefox preferences value (e. g. network.http.charset_quirk_level) controlling browser’s behaviour. • Make patches for the source code to be used only by those who are interested. Possible approaches to relation between two scenarios include: • Extend the meaning of the «X-Content-Type-Options: nosniff» to banning the toxic UTF sniffing. • Make interpretation of «X-Content-Type-Options» depend on preferences. • Invent a new value for X-Content-Type-Options, or a new header at all, in a hope other browsers and Web applications will ultimately adopt it. • Treat two problems completely separately. Opinions? Please note, I’m not (yet) a browser developer and my main agenda is making a browser I could trust myself. Regards, Incnis Mrsi ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: dialog=1 for window.open from content
On 10/1/15 1:34 PM, Mike Conley wrote: I'm currently working on bug 1095236 - that's an e10s bug for us failing to open any windows if the features string includes dialog=1 (or dialog=yes). According to [1], setting dialog=1 makes a popup window that removes the min/max/restore buttons, and no "command" menu (the icon usually appearing in the top left which opens the Restore, Move, Size, etc options). Note that this is only really apparent on Windows, where we default to having such buttons on popups. What does this currently do in non-E10S mode? And what do other browsers actually do? I generally think we shouldn't do too much special here. Especially considering that this argument doesn't even make much sense on platforms with a radically different notion of "window" (ie, mobile). ISTR that window.open() once used to allow lots of this kind of stuff back in the Web 0.8 days, and its functionality has been pared down over the years due to UX and security concerns. Justin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
dialog=1 for window.open from content
Hello dev-platform, I'm currently working on bug 1095236 - that's an e10s bug for us failing to open any windows if the features string includes dialog=1 (or dialog=yes). According to [1], setting dialog=1 makes a popup window that removes the min/max/restore buttons, and no "command" menu (the icon usually appearing in the top left which opens the Restore, Move, Size, etc options). Note that this is only really apparent on Windows, where we default to having such buttons on popups. Also according to [1], Gecko is the only web engine to support that feature. Before I go whole-hog trying to fix bug 1095236, I'm curious to know if we really want to continue supporting dialog=1 from content, or if it's safe to just ignore that feature like the other browser engines (which I think would be the fastest path towards fixing bug 1095236). Are there any really good arguments to keep supporting it? -Mike [1]: https://developer.mozilla.org/en-US/docs/Web/API/Window/open?redirectlocale=en-US&redirectslug=DOM%2Fwindow.open#Window_functionality_features ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ Core Guidelines
For those who are interested in this, there's a bug to consider integrating the Guidelines Support Library (GSL) into the tree: https://bugzilla.mozilla.org/show_bug.cgi?id=1208262 On 30/09/2015 22:00, Botond Ballo wrote: Hi folks, I wanted to draw your attention to a new project underway in the C++ standards community. It's a document called "C++ Core Guidelines" [1], intended to be a collection of widely applicable C++ best practices, that can serve as a template on which C++ projects can base their own, more specific guidelines. The document is a work in progress, still incomplete in many places. The initial authors are Bjarne Stroustrup and Herb Sutter, two members of the C++ Standards Committee, and they welcome contributions via GitHub to help complete and improve it. At some point (probably some time later when the guidelines are more complete), we may want to see if there's anything in there that we'd like to lift into our own Mozilla guidelines. Cheers, Botond [1] https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
