Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)
On 7/15/2015 5:47 PM, Andrew Sutherland wrote: Would it be crazy for us to resort to a poll on these things? A poll will not be useful for informing this decision. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)
On 7/8/2015 7:31 AM, Nathan Froyd wrote: If somebody is willing to do the formatting, I'm willing to do the review. I think the thread has reached the point of people repeating ad nauseum what was already said earlier in the thread, so it's time for a decision. Benjamin? Aww, I was avoiding getting into this thread. I personally have no strong preference, and our existing community is pretty deeply divided. I doubt we're going to come to consensus here, and this is a pretty tough decision to make on its own. I do believe that consistency trumps module/personal preference in terms of coding style. The argument I am most sympathetic to is that this convention is a barrier to new contributors. Making new contributors productive, both employees and volunteers, is a very good reason to choose one style over another. Given that premise, we shouldn't just change aArgument; we should adopt the Google C++ style guide wholesale: * names_with_underscores * members_with_trailing_ * no more ns prefix There is good research that underscore_names are more readable, and many of these will be more familiar to new contributors. Also we have a fair bit of shared code with Google. If there is a decision to be made here, I'd like to make this RFC: * switch our codebase wholesale to the Google C++ style guide With the following implementation plan: * For now, code should continue to be written in the current style with aFoo, mFoo, and camelCase. * get our code -Wshadow clean * Ask poiru to investigate auto-renaming of our variables including mFoo, aFoo, and camelCase to the google-standard local variable names. * Do not make any changes to the style guide or standard practice until we're comfortable that we can do automatic changes. * Make the automatic changes and change our style guide at roughly the same time. * Go back and deal with class names (nsFoo) as a separate/later pass. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: GTK3 linux builds
On 6/16/15 4:16 PM, Jeff Muizelaar wrote: We're working on making all of the tests green for GTK3. This means that we could be changing the default linux configuration to GTK3 as early as FF42. What are the advantages of the GTK3 build? Is there a list of which distros/versions would continue to work and which would stop working? Do we have a plan not to update existing users who would be broken by the new builds? I seriously doubt we should spend a lot of time Are there issues with plugin compatibility in GTK3 builds? I seriously doubt we want to spend release resources on shipping and doing release checks on multiple Linux builds (I think we've even discussed dropping Linux x86 support). In case it's not clear, I'm skeptical that we should do this. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Firefox Data Collection Practices - How to Collect Data
I'd like to point Firefox and platform developers at this doc: https://wiki.mozilla.org/Firefox/Data_Collection Several times recently I've discovered that developers are unsure what the rules are for collecting data. Last year, I worked with Marshall Erwin to clarify decision-making about data collection and we came up with these guidelines and policies. The scope of my role as Firefox data steward includes understanding and reviewing the data the Firefox client sends back to Mozilla. This includes things like AUS pings, add blocklist pings, Firefox features that are delivered as a service (Hello, Accounts, Sync), as well as the actual data-collection features including telemetry, FHR, crash-reporting, heartbeat, etc. As necessary I will work with Marshall and Geoff from the legal team if there are legal concerns about any data, and to keep the Firefox privacy notice up to date. One of our biggest goals when doing data collection review is to ensure that the data collection is properly documented. For telemetry probes this may be self-documenting within Histograms.json itself, but for many other pieces of data, we will ask you to update the in-tree .rst docs to describe the data that is being collected. I have been listing out our existing data collection mechanism, many of which are not well-documented currently. You may see an email from me in the next few months asking for better docs for the existing data collection mechanisms. The data steward and data collection review replaces the older privacy review mechanism. Our goal is to review the data we collect not just privacy concerns, but to make sure that the data will be able to answer the questions you want to ask and that there is somebody responsible for monitoring the data after it has been collected. I would like to review all changes to data collection, including new telemetry probes, crash-stats annotations, etc. Vladan Djeric and Ally Naaktgeboren are my peers to help expedite data collection reviews: feel free to request review from any of us. Please let me know if you ever feel stuck or blocked on data review: my goal is to get simple requests approved very quickly, and make sure more complex requests don't ever get stuck or have a clear owner. My role as Firefox data steward does not extend to Firefox OS: the data steward for Firefox OS is Jonas Sicking. Also, my role does not extend to the servers which store data after it has been collected: the Firefox cloud services data steward is Travis Blow. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Update: Intent to Ship Adjust SDK in Fennec
On 5/20/2015 1:07 PM, Winston Bowden wrote: We've done an enormous amount of due diligence prior to integration. Adjust went through a legal and privacy review. It also went through and open source review/analysis. As the data steward I've been working with both Winston and the engineering teams on this, and the data collection system is documented using the in-tree doc system: https://gecko.readthedocs.org/en/latest/mobile/android/base/fennec/adjust.html The Android advertising ecosystem isn't very healthy, but Adjust is a service provider that takes great care with their data collection and retention practices to reduce risk to users while measuring advertising spend and effectiveness. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to alter the coding style to not require the usage of 'virtual' where 'override' is used
I think it's time I made an official decision here. I think Ehsan's proposal makes a lot of sense both as good engineering and because we know Google has already proved it for us. I approve. Ehsan, will you please make the necessary changes to our style guide? --BDS On Mon, Apr 27, 2015 at 3:48 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: Right now, our coding style requires that both the virtual and override keywords to be specified for overridden virtual functions. A few things have changed since we decided that a number of years ago: 1. The override and final keywords are now available on all of the compilers that we build with, and we have stopped supporting compilers that do not support these features. 2. We have very recently gained the ability to run clang-based mass source code transformations over our code that would let us enforce the coding style [1]. I would like to propose a change to our coding style, and run a mass transformation over our code in order to enforce it. I think we should change it to require the usage of exactly one of these keywords per *overridden* function: virtual, override, and final. Here are the advantages: * It is a more succinct, as |virtual void foo() override;| doesn't convey more information than |void foo() override;|. * It can be easily enforced using clang-tidy across the entire code base. * It makes it easier to determine what kind of function you are looking at by just looking at its declaration. |virtual void foo();| means a virtual function that is not overridden, |void foo() override;| means an overridden virtual function, and |void foo() final;| means an overridden virtual function that cannot be further overridden. * It allows us to be in sync with the Google C++ Style on this issue [2]. * It will allow us to remove NS_IMETHODIMP, and use NS_IMETHOD instead. Please let me know what you think! [1] Facilitated by bug 904572. Also see bug 1158776 for my first attempt at this. [2] http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Inheritance Cheers, -- Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- Benjamin Smedberg Engineering Manager, Firefox ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: No more binary components in extensions
On 5/4/2015 6:53 PM, Philipp Kewisch wrote: So to be clear, this is just removed/disabled for Firefox? Other projects like Thunderbird are not affected? Followups to dev-extensions please! That is incorrect. This is currently disabled for all gecko applications. B2G has asked that binary component support be restored for distribution/bundles only, and that is being done in bug 1161212. As I said on the other list, I will review a patch which makes this configurable for Thunderbird, but I don't plan to write that patch myself. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
No more binary components in extensions
(Followup questions or comments to mozilla.dev.extensions only, please.) With the landing of bug 1159737, I have removed support for binary XPCOM components in extensions. This is planned to ride the Firefox 40 train. This change is necessary because we no longer expose or intend to expose a binary-stable API to XPCOM. Most addons have already moved away from binary XPCOM components, but those that haven't are a source of instability around Firefox releases. Extension authors that need to use native binaries are encouraged to do so using the addon SDK system/child_process pipe mechanism: https://developer.mozilla.org/en-US/Add-ons/SDK/Low-Level_APIs/system_child_process If this is not sufficient, JS-ctypes may be an alternative mechanism to use shared libraries, but this API is much more fragile and it's easy to write unsafe code. I will be updating MDN documentation and removing or archiving old documentation about binary XPCOM components in the next few weeks. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to alter the coding style to not require the usage of 'virtual' where 'override' is used
I think this is a good plan, and the harmony with the Google style guide is a nice incidental benefit. Does this mean that every c++ *must* be marked with override, or is that still optional? Do we intend to make that a requirement in the future? --BDS On Mon, Apr 27, 2015 at 3:48 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: Right now, our coding style requires that both the virtual and override keywords to be specified for overridden virtual functions. A few things have changed since we decided that a number of years ago: 1. The override and final keywords are now available on all of the compilers that we build with, and we have stopped supporting compilers that do not support these features. 2. We have very recently gained the ability to run clang-based mass source code transformations over our code that would let us enforce the coding style [1]. I would like to propose a change to our coding style, and run a mass transformation over our code in order to enforce it. I think we should change it to require the usage of exactly one of these keywords per *overridden* function: virtual, override, and final. Here are the advantages: * It is a more succinct, as |virtual void foo() override;| doesn't convey more information than |void foo() override;|. * It can be easily enforced using clang-tidy across the entire code base. * It makes it easier to determine what kind of function you are looking at by just looking at its declaration. |virtual void foo();| means a virtual function that is not overridden, |void foo() override;| means an overridden virtual function, and |void foo() final;| means an overridden virtual function that cannot be further overridden. * It allows us to be in sync with the Google C++ Style on this issue [2]. * It will allow us to remove NS_IMETHODIMP, and use NS_IMETHOD instead. Please let me know what you think! [1] Facilitated by bug 904572. Also see bug 1158776 for my first attempt at this. [2] http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Inheritance Cheers, -- Ehsan -- Benjamin Smedberg Engineering Manager, Firefox ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: changing the default platform and operating-system on bugzilla.mozilla.org to all / all
On 4/14/2015 11:40 AM, Dave Townsend wrote: Are the platform fields actually useful? Most bugs apply to all platforms and in the cases that don't it is normally clear from the bug conversation that it is platform specific. It seems like we rarely go an update the platform fields to match the actual state of the bug. And then there is the problem that OS doesn't allow for multi-selections where say a bug affects a few versions of Windows or Windows and OSX. I've gotten used to just ignoring these fields and reading the bugs instead. I wouldn't feel any loss if they were just removed from display entirely. I've suggested this before (and still think that's the right user experience). In fact this turns out to be really difficult to do within bugzilla because those fields are baked into bugzilla guts and removing them would require not just hiding them on the edit-bug page but also from the query pages and various other locations. I do think we should try to stop using these fields for anything important. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
The e10s throbber
With desktop e10s on there can be a noticeable delay after switching tabs where there is a throbber displayed before the page content. Is the duration of this delay measured in telemetry anywhere, and do we have criteria for how much delay is acceptable in this case? If e10s were off, do we expect that this same delay would occur but would just show up as a jank switching tabs? Or is this a perf problem unique to e10s? --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: FYI: Serious windows bug affecting WebRTC when mem use is over 2GB
On 3/26/2015 3:00 AM, Randell Jesup wrote: Force a buffer in 2GB memory and always copy into/out of that buffer? That may work, other than it's inconvenient to force a buffer into 2GB space at the time when you need it, and thus we'd have to perma-allocate a large enough buffer for this. You don't have to commit it, you only have to reserve the address space. (Note GetAdapters*() is typically used with a first call to get the size, then a second to get the real data, or with a 16K-ish buffer then redone if that isn't enough.) What is the largest buffer that we can expect to need? Since VM allocation happens in 64k boundaries, is it sufficient to just use a 64k buffer for this? What thread(s) are these functions called on? Can we serialize access to them so that we can allocate just one buffer at startup and use that singleton for all the callers? --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Fwd: [blink-dev] Intent to Ship: Plugin Power Saver Poster Images
On 2/7/2015 4:38 AM, Jet Villegas wrote: We should pick this up too. I'm skeptical of the immediate value. We need to focus on Flash hangs and also the security issues surrounding Flash 0-days especially as distributed by ad networks. Power saving is not our immediate or medium-term focus. It seems that this proposal focuses on authors opting in, and providing a better experience for per-element click-to-play behavior. What fraction of existing Flash has a usable poster? By adopting this proposal, would we also be adopting a per-element click-to-play approach? If so, is this for all 3rd-party Flash, or just for known advertising sites, or for all Flash? User studies have shown that typically users won't understand the difference between Flash and the browser, and the extra click isn't a usable solution for most people. If we can be confident of limiting this to advertising, that evaluation might change (because users are used to clicking on advertising already). Note that if we're talking about something other than poster attributes, I have more serious concerns: the differences between windowed and windowless Flash are significant, and our control over windowed Flash is pretty minimal. In order to do automatic posterization the way Safari does it, we'd need to ensure that the elements are windowless, *or* we'd need to invent a pretty complex mechanism for control over windowed Flash and taking snapshots of windows. I'd encourage somebody to implement this as an addon or behind a hidden pref, and see what the experience is like and whether users like it. It should be possible to implement this as an addon. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Firefox desktop platform team: Q1 areas of focus
I wanted to shared publicly the projects and areas of focus that the Firefox Desktop Platform team in Q1. *Video quality issues, especially Flash video:* We have market data which indicates that one of the most important pain points for Firefox users is problems with video. We have several projects across Mozilla to help improve this, including MSE so that youtube can stop using Flash, and implementing video fallback in Shumway instead of in Flash for common video sites. In specific, my goal is to reduce by half the number of users who experience plugin hangs/deadlocks, which are currently very common on Windows. *e10s:* the focus of our team in particular will be making sure that e10s performs well and has proper measurement systems. This includes updating telemetry to work with e10s, Talos metrics, and other e10s-specific quality metrics. We will use these metrics to prepare a recommendation for e10s riding the trains to beta and then release. *Telemetry/FHR Unification: *This will combine FHR and telemetry back into a single client/server measurement system similar to the current telemetry session-based measurement infrastructure. This involves both client and server work on our team, and is being done along with the services engineering team who will be maintaining the data ingestion infrastructure and the metrics team who uses the data for analysis. This will ride the Firefox 38 train. *Update Orphaning: *We currently have too many users stuck on old versions of Firefox. This quarter we will be making a concerted effort to measure the reasons that users get stuck on old versions and implement fixes. Our current orphaning rate is 2% of users per 6-week release cycle, and by the end of the year we intend for this to be below 0.5%. *Catastrophic Memory Usage: *Some Firefox users especially on Windows are experiencing huge memory usage and common OOM crashes. This is not common to all users, but appears to affect particular configurations. Our goal last quarter which carries into this year is to diagnose the most common causes of this problem and work with the appropriate engineering teams to solve the problems. Currently this effort focuses on data from crash-stats, but it appears that it may be necessary to add specific measurement of these problems to telemetry in order to properly understand the issues. Questions or comments welcome. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Updating the policy for Talos performance regression in 2015
On 12/19/2014 10:05 AM, Ehsan Akhgari wrote: Acceptable outcomes: * A promise to attempt a fix at the bug is agreed upon, the bug is assigned to someone and put in a queue. How do we ensure that the follow-up bug actually does get fixed and it fixes the regression completely? Avi/Vladan will be tracking these and nagging as appropriate. * The bug will contain enough details and evidence to support accepting this regression, we will mark it as wontfix * It is agreed that this should be backed out Do we plan to have a different approach towards more severe regressions? For example, if a patch regresses startup time by 50%, would we still accept evidence to support that the regression should be accepted, or would we tolerate it in the tree for a few weeks before it gets fixed? I don't think this can be answered in advance. If we're in this situation, it will be because we're making some huge cost/benefit tradeoff and we have high confidence that the regression can be fixed or that it's worth the corresponding benefit. Product managers would likely be involved in making the final decision based on a technical recommendations from the engineers and the performance team. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Critical - XULRunner 34 fails with Couldn't load XPCOM in MacOSX
On 11/27/2014 10:38 PM, allencb...@gmail.com wrote: I've reported this in bugzilla. Any one has any workaround? I commented in the bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1105044). This is probably due to the MacOS v2 signing work which restructured the bundles. Since XULRunner is not maintained, you or other XULRunner users will probably have to debug this to figure out what's going on and propose a solution. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: How do you run unit tests against Firefox?
On 11/12/2014 5:49 PM, Nicholas Nethercote wrote: What exactly do you mean by unit tests? I presumed that this meant all of our pass/fail test suites (not the performance tests): xpcshell, the various flavors of mochitest, reftests, etc. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Changing our help messages to mention --foo options instead of -foo options
On 10/23/14 9:20 PM, Nicholas Nethercote wrote: Hello. Our command-line option handling is *interesting*. Did you know that: - our options work in -foo form and --foo form; - they are case-insensitive; - this holds for both short options (e.g. -h) and long options (e.g. -help). I did in fact know this, but I may be one of the few. This dates back to the pre-FF1.0 days where we had different startup paths for windows/mac/linux each of which had their own arg handling code with different expectations. My decision was to accept all the different varieties of argument and treat them equivalently. At least, all this is true for the options that are processed via the main option-processing code. Some of our options are handled elsewhere, via ad hoc code that is generally less flexible. Can you point me to this? Pretty much any code handling command lines should either be use the nsAppRunner code or using the nsICommandLine APIs. Before I land those patches, I thought I would ask here if anyone can see any reason not to do this. Remember, it's not a functional change -- both -foo and --foo options will still work -- it's just a documentation change. Doesn't matter to me. Another obvious follow-up is to drop support for -foo options, but that's *much* harder, so I haven't even bothered filing a bug about that. I don't think we should ever do this. It would break some existing user for no apparent benefit other that consistency with standard command-line conventions. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
gtests that start XPCOM
Is there a mechanism for running single gtests that start XPCOM? With the current gtest mechanism, normal gtests can't start XPCOM (NS_InitXPCOM, event loops, component manager, etc) for various reasons: * gtests are run in parallel and XPCOM has globals and thread-locals which don't allow that kind of multithreading * XPCOM doesn't support being re-initialized after it has been shut down, and supporting that is a huge task that is unlikely to be a good idea However, I've heard that there are some media tests which do initialize XPCOM: https://wiki.mozilla.org/Media/WebRTC/Testing I am currently attempting to convert at a few C++ unit tests which start XPCOM and also end up using bits of JSAPI: toolkit/components/places/tests/cpp/test_IHistory.cpp uses JSAPI via nsINode-nsWrapperCache-RootingAPI media/webrtc/signalingtest uses nsPIDOMWindow - nsINode - nsWrapperCache - RootingAPI I'd like to convert these to be use the gtest-libxul. Do we have a framework for gtests that start XPCOM and therefore need to be run one at a time rather than using the normal parallel-gtest mechanism? --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: gtests that start XPCOM
On 10/22/2014 10:49 AM, Kyle Huey wrote: I've been wanting this too. I was thinking about just making the gtest harness itself start XPCOM. - Kyle I don't think that's quite right. 1) We'd have to serialize a bunch of tests 2) it would be really easy for tests to interfere with eachother. What I'd us to do is split gtests into two: keep the existing no-XPCOM pure parallelizable gtests, and have a separate suite which is more like a binary xpcshell tests: one process per test which uses no profile or a throwaway profile, and any parallelization is handled by the harness. It would use the same gtest-libxul so that we could compile in arbitrary test code which uses internal linkage. I'm not sure how hard that would be to implement, though. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Win64 builds tests coming soon!
On 10/21/2014 8:37 PM, Gijs Kruitbosch wrote: Is there a tracking bug for the work on 64-bit itself? There is bug support-win64. But at this point most of these bugs aren't being tracked as part of a win64-specific project, but more as work for each team to prioritize. If there are serious issues, please nominate them for release tracking as you would for 32-bit builds. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Compiler version expectations
On 10/16/2014 3:49 PM, Jeff Muizelaar wrote: After some discussion some IRC it was clear that our compiler deprecation schedule is not very clear. Now that we’re using VS2013 on trunk and will soon not being using GCC 4.4 for B2G, I expect we’ll be dropping support for building with VS2010 and GCC 4.4 in the near term. This is important to us because Skia is planing on using more C++11 features in the near term and we’d like to continue updating from upstream. Are there reasons we can’t drop support for these compilers in the 37-38 time frame? I can't speak to the GCC issue, but we intend to continue support for MSVC2010 at least through the 36 train, in case a regression is found which is serious enough to cause us to revert. If there are no serious issues found, I think it is reasonable to require MSVC2013 in six weeks. If we do that, I'd want somebody to actually make 2010 fail early in configure. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Tool for generation of regression-range links
tl;dr: I have a tool for generating regression-range links from buildids. http://bsmedberg.github.io/firefox-regression-range-finder/ Often times when we're investigating regressions (crashes, etc), we have the build ID of the nightly where the regression started. But it's not the easiest thing in the world to turn that into an actual pushlog link which lists the commits in the regression range. To help fix this, I've created a tool that lets you paste in a buildid or two and automatically figures out the proper regression range link, and also links you to the nightly build directories. This tool is pretty hacky: it loads http://ftp.mozilla.org directory listings to find builds, and then loads the .txt files describing the revisions involved. If we ever changed webserver for ftp.mozilla.org the tool would likely break. But since it's something I do at least once a week and I know other QA people do this even more regularly, I figured it was worth automating. Right now the tool uses ES6 features `let` and `for...of` and so it only works in Firefox and not in Chrome. I figured for this audience that wouldn't be a problem. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: c++ unit test in content process
On 10/3/2014 4:59 AM, Patrick Wang wrote: Hi, I am trying to write a C++ unit test for code that runs in child process, but all c++ tests I found run in parent process. Is it possible to write a c++ test case that runs in child process, or is there any example in our code? Could you be more specific? We have the following possible harnesses: gtest - typically these tests are low-level C++ tests and often don't initialize XPCOM at all. Certainly they don't have the concept of chrome/content processes. xpcshell - typically test the API surface of a component written in JS or C++ Neither of these particularly care about chrome/content: if you're actually testing a C++ component and not doing integration testing, is it possible that you don't need to care? --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: c++ unit test in content process
On 10/3/2014 9:46 AM, Patrick Wang wrote: The test I am writing is to test an implementation of WebRTC's TCP socket in content process. These codes are build on top of TCPSocket's IPDL in C++ and don't have IDL so it cannot be called directly from JS, and the tests for chrome process version are written with gtest. Therefore I am thinking of writing a similar one with gtest but run in content process. Does the unit of code you're testing include two processes communicating via IPDL? If so, I think you're going to need something more than a C++ unit test, and should probably focus your efforts on a more end-to-end integration test. Setting up IPDL connections and all of the machinery that goes with that doesn't sounds like something we should be trying in low-level unit tests. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Upcoming changes to Mac package layout, signing
On 8/28/14, 1:04 AM, Dave Townsend wrote: If my reading of the patches are correct then the extension manager will start looking in the new location in the app bundle for extensions (Contents/Resources/browser/extensions) automatically. We'll have to support this as that is where the default theme is to be found. We should support this as little as possible. If anyone actually *did* drop extensions into that location, it may break the application signature for users. And even worse, the signature break might not show up immediately, but whenever MacOS decides to re-check the signature. I suggest that to the extent we have to have a default theme there, we should explicitly limit this location to only the default theme. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: ./mach build subdirectory doesn't work reliably any longer
On 8/27/14, 9:47 AM, Gregory Szorc wrote: I interpret this this use case as building a related set of object files for the purpose of quick/imprecise validation of changes to a specific component. So what you really want is to build specific modules. Is that accurate? That sounds like a complex way to phrase it: how about I changed some files in toolkit/locales and toolkit/modules and I'm pretty sure there aren't external dependencies, so I just want to rebuild toolkit/* to see those changes. I've done something similar with mach build browser/experiments mach build browser/locales mach build toolkit/modules, although I'd really love that to just be mach build browser/experiments browser/locales toolkit/modules. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: ./mach build subdirectory doesn't work reliably any longer
On 8/27/14, 10:22 AM, Gregory Szorc wrote: There is additional cognitive load required to map a logical feature into a set of directories. I would prefer this burden go away, as it only breeds confusion and a higher barrier to contributing (new contributors don't know these shortcuts so they sit through painfully long full builds). I don't understand. I didn't pick these directories because there was any concept of a logical feature: I picked those because those were the files that I edited. That seems like the least-posssible cognitive load in general. Also, for the JS-centric use case you mentioned, if we invested in those parts of the build system, we could probably get full tree builds with no binary changes to under 10s. e.g. |mach build nonbinaries|. Sure. But since we don't have that yet, let's make sure that thing we did have keeps working? Is returning to the prior behavior by making `mach build dir` recursive a complex fix? --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Handing over XPCOM module ownership to Nathan Froyd
Over the past year, Nathan Froyd has been an excellent peer for the XPCOM code module, providing thoughtful and fast reviews and guidance. I'm happy and excited to hand over ownership responsibilities to Nathan. I have been a peer/owner of XPCOM for close to ten years now, since before I was a Mozilla employee; my first big patch to Mozilla in 2002-2003 was to add the C++ hashtable templates nsTHashtable and friends. Now it's time for me to focus on new management responsibilites as well as Firefox data collection and privacy. It's a relief and joy to be able to hand off this responsibility with confidence. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Switching to Visual Studio 2013
On 8/23/2014 6:15 AM, Neil wrote: David Major wrote: * No more linker OOM crashes. VS2013 includes a 64-bit toolchain for 32-bit builds, so the linker will no longer be limited to 4GB address space. So will you be requiring 64-bit builders? For PGO builds, probably yes. For normal developer builds this is not an issue. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Switching to Visual Studio 2013
On 8/22/2014 5:04 AM, xunxun wrote: And we should use VC2013 update2 or newer edition, whose PGO is faster than WPO. Yes, we had to wait for update 2 for fixes that would allow Firefox PGO builds to complete at all (there were previously internal compile errors during the link phase). Update 2 is already deployed to all of our windows builders and David is doing try builds and working on the last few issues from that. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Switching to Visual Studio 2013
On 8/22/2014 10:34 AM, Gijs Kruitbosch wrote: Do we have a configure check for this so people trying this won't waste oodles of time only to get internal errors? :-) No we don't. It only affects PGO builds, which no normal person ever does, so I think the relative effort of implementing and testing a configure check probably isn't worth it in this case. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Experiment with running debug tests less often on mozilla-inbound the week of August 25
On 8/20/2014 3:07 AM, Mike Hommey wrote: Optimized builds have been the default for a while, if not ever[1]. Bug 54828 made optimized builds the default in 2004 right before we released Firefox 1.0. It only took four years to make that decision ;-) --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Upcoming changes to Mac package layout, signing
On 8/13/2014 3:34 AM, Philipp Kewisch wrote: Does this also affect binary extensions in any way? I'd imagine that globally installed extensions would break signing if placed incorrectly. You cannot place anything in the Firefox bundle. Any extensions, binary or not, would need to be elsewhere. I don't know that we have a supported global install location on Mac. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Getting rid of already_AddRefed?
Just reading bug 1052477, and I'm wondering about what are intentions are for already_AddRefed. In that bug it's proposed to change the return type of NS_NewAtom from already_AddRefed to nsCOMPtr. I don't think that actually saves any addref/release pairs if done properly, since you'd typically .forget() into the return value anyway. But it does make it slightly safer at callsites, because the compiler will guarantee that the return value is always released instead of us relying on every already_AddRefed being saved into a nsCOMPtr. But now that nsCOMPtr/nsRefPtr support proper move constructors, is there any reason for already_AddRefed to exist at all in our codebase? Could we replace every already_AddRefed return value with a nsCOMPtr? --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Getting rid of already_AddRefed?
On 8/12/2014 12:28 PM, Joshua Cranmer wrote: But now that nsCOMPtr/nsRefPtr support proper move constructors, is there any reason for already_AddRefed to exist at all in our codebase? Could we replace every already_AddRefed return value with a nsCOMPtr? The rationale for why we still had it was that: nsIFoo *foobar = ReturnsACOMPtr(); silently leaks. Really? I thought that in this case there would be no leak because the (temporary-returned) nsCOMPtr destructor would properly free the object. The problem is that `foobar` potentially points to an object which has already been released. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Are StaticAuto/RefPtr good?
On 8/8/2014 11:25 AM, Ehsan Akhgari wrote: The problem I was mentioning is not related to the leak at all. What if one of these destructors runs code that writes something to the disk for example, which we expect to go to the disk before we shut down? Then we should assert in debug builds! Perhaps we should even assert that such pointers are cleared by the end of XPCOM-shutdown, although that's more complexity. We will have already shut down XPCOM and the profile will be unlocked, so it is very likely that in such a scenario the write will succeed, go to the correct place, or not be a risk of dataloss. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Are StaticAuto/RefPtr good?
On 8/6/2014 1:20 PM, Chris Peterson wrote: I don't understand this sentence, but I strongly oppose automatically clearing Static*Ptr in the static destructor in any build. In the past we have had static comptr cause final release of objects after XPCOM shutdown, which causes crashes due to the component manager or CC or other infrastructure already being shut down. Wouldn't that be a bug that should be fixed? Sure, it's a leak bug that should be fixed. But since figuring out whether a late release will cause a crash or a security issue or is harmless is hard, it's better to assert in debug builds and leak in release builds than to clear in release builds. So far I don't think anyone has proposed crashing in release builds, which I don't think is worth the risk. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Deprecating localstore.rdf
On 8/5/2014 9:14 AM, rviti...@mozilla.com wrote: What do you mean exactly by addon validation warning? I mean an rule in the AMO automated checking/validation system: normally they are simple grep rules to detect that an addon is using an obsolete interface or code pattern. This will warn on new addon uploads; it's also used sometime near release to warn addon authors about potentially breaking changes. Talk to Jorge about the details of getting this kind of rule added to the validator. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Deprecating localstore.rdf
On 7/22/2014 8:47 AM, Roberto Agostino Vitillo wrote: Localstore.rdf will soon be replaced with a json store (see Bug 559505). I am currently planning to leave the localstore.rdf implementation as it is and issue a warning when a client tries to access to it. This is needed as some add-ons seem still to rely on it. We could use some Telemetry probes to see effectively how many add-ons are still using the rdf store once the patch lands. Are there any objections or remarks to the deprecation of localstore.rdf? This does involve a one-time import of localstore data into the new format, correct? I'm happy that we are doing this. I *believe* that this may be the last client of the RDF code in Firefox, which may allow us to remove RDF from Firefox in a future release. Do you already have an addon validation warning about addons using localstore? --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Deprecating localstore.rdf
On 8/4/2014 5:06 PM, Gavin Sharp wrote: This is certainly a big one, but https://bugzilla.mozilla.org/showdependencytree.cgi?id=833098maxdepth=1hide_resolved=1 suggests we will still need to worry about mimeTypes.rdf and install.rdf/update.rdf, unfortunately... ok. mimeTypes.rdf is read/write and so we'd need to replace it. install/update.rdf are read-only and so we could use the simple JS shim library pretty easily. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to deploy: plugin timeout A/B test experiment, bug 1018200
This is an official notice of intent to deploy the experiment in bug 1018200 to the beta channel. The experiment is an A/B test to determine the optimal value of the dom.ipc.plugins.unloadTimeoutSecs on the FF32 beta. This setting determines primarily how long we wait to unload Flash and other plugins after a user isn't using it any more while browsing. Users in the experiment will be grouped into 8 equal groups whose timeouts will be set to various values: 0, 5, 15, 30, 60, 90, 120, and 300 seconds. The experiment parameters are: MinVersion: 32.0 MaxVersion: 34.* Start Date: 01-Jul-2014 End Date: 02-Sep-2014 Maximum runtime: 42.0 days Update Channels: beta Sample Rate: 5% Low-priority experiment: this experiment is lower-priority than the translation experiment already scheduled for beta, so any users eligible for that experiment will participate in that one first. A reminder that the experiment system only runs one experiment at a time, so there is no chance of multiple experiments conflicting. To analyze the results I intend after 2-3 weeks to correlate the experiment groups against the telemetry measurement for plugin launch time (bug 1011136). This will tell us both how often users are launching plugins, but also how long those plugin launches take. My intent is to pick a final value for this preference based on the data before we ship FF32 to release. Chad, I'm looking for your approval to use 5% of the beta population for this experiment. Release-drivers, I am looking for your approval to enable this experiment as soon as Kamil completes QA verification on staging. gps, I would like you to take care of getting this experiment deployed to production when everything is ready and monitoring the deployment, since I will be on vacation. I want to thank Qeole, a contributor who implemented the correct timeout setting, the telemetry probe, and this experiment all himself. He/she has done this thoughtfully and well. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deploy: plugin timeout A/B test experiment, bug 1018200
On 7/16/2014 3:35 PM, Jet Villegas wrote: after a user isn't using it any more How good are we at determining any more? We start counting when the last instance for that plugin is destroyed (NPP_Destroy). --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: Refcounted classes should have a non-public destructor should be MOZ_FINAL where possible
On 7/10/2014 10:46 AM, Daniel Holbert wrote: First, if your class is abstract, then it shouldn't have AddRef/Release implementations to begin with. Those belong on the concrete subclasses -- not on your abstract base class. What's correct code for abstract class Foo (implementing interfaces IFoo1 and IFoo2) with derived classes Bar and Baz (implementing interfaces IBar1 and IBar2 or IBaz1 and IBaz2 respectively)? Shouldn't the refcounting still be on the concrete classes? Why? This happens for example with nsRunnable: nsRunnable does the refcounting, and all the derivations of nsRunnable only have to worry about overriding Run because there's a virtual destructor. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rethinking the crash experience
On 7/9/2014 4:46 PM, Robert Kaiser wrote: Most probably would not type a comment when they're not immediately prompted for it. We could do an experiment around it, but I'd be surprised if anything else comes out of it. There's no reason to guess or use personal anecdotes for this. We'll do experiments around optimal flow and around optimizing for best submission rate and best comment rate. We may choose different UI options for the prerelease channels where we want to optimize for comments and the release channel where we want to optimize for user flow and good overall submission rates. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Capturing the JS stack in case of crash
On 7/8/2014 9:25 AM, David Rajchenbach-Teller wrote: Often, we find ourselves attempting to debug JS code that causes a crash, generally by miscalling a XPCOM component that causes an assertion failure. Unfortunately, in such cases, the native stack captured gives little to no indication that can help developers find out how we reached this specific assertion. This is true both when we run code locally, on Try or when Firefox is released to users. Could we find a way to capture the JS stack? I have the impression that it would be sufficient to modify our assertion macros to call a DumpJSStack() equivalent before actually crashing, and to attach the output to the Crash Reporter if available. We've wanted something like this for a long time, but it's really hard to get right in the general case. The hazards involved include: * asserts sometimes happen within mutexes which could mean deadlock hazards * Depending on the situation, we might not even have the JS engine initialized yet * Does the JS stackwalker ever trigger GC or other callbacks into gecko? We really can't stand re-entrancy in this case. Does it matter if the JS code in question is currently in a JIT frame versus an interpreted frame? * Since asserts are usually signs of broken code to begin with, we need to be very defensive both in terms of security and additional crash protection. In the naive case of somebody who is currently using nsIDebug.abort from JS code, I suspect most of these objections don't apply, and we could do this fairly safely. But I'm not so sure it's something we should do in the general case. The other thing to consider is whether we can change the JS engine so that the stack can be reconstructed from information in the minidump itself. Especially if we can localize the stack data into a small number of pages/pseudostack, that might be a better way to approach the problem here. But it's also likely to be a big engineering effort. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rethinking the crash experience
On 7/5/2014 8:21 AM, David Rajchenbach-Teller wrote: Could we redesign this as follows? 1. Something goes wrong in the code of Firefox; 2. Firefox dies; 3. Crash report is stored to disk, without any dialog; 4. If the crash happened during Firefox shutdown, do nothing, otherwise restart Firefox to its previous state (obviously, we need some measure to prevent this from looping); 5. Upon the next restart, display a bottom doorhanger on all windows Firefox or an add-on encountered a problem [a few seconds ago / on July 4rd, 2014] and recovered. If you wish, Firefox can report it automatically so that we can fix the bug report/not this time/always report/never report. Yes, we should do something like this. It's not what we're going to focus on right now, though. Here's the current plan: * measure crash submission rates in FHR. Bug 994707 and 994708. * implement the support-after-crash project so that we can provide actionable results to users after a crash, based on their crash submission. This is a Q3 project that Birunthan is working on (https://docs.google.com/document/d/1dZkkjDh87k4UH4Gcv_gA_pkTo8yIR88l_Dxs2fXKJRs/edit?usp=sharing), and is very intertwined with the project to improve automatic user support for non-crash issues such as unwanted addons, incorrect settings, and failure to update * Explore some better UI options for crashes. Implement various options and measure the actual crash submission rates we get. We may need to go back and revisit some decisions we made in 2007 about how we didn't want an always submit my crashes option in the UI. We may also need to improve our crash report server to for example accept comments about a crash after it was submitted. If we end up in a situation where we're trading off a seamless restart flow versus crash submission rates, I'm not convinced that seamless flow is the correct choice. But we don't know yet what the options are or what user behavior will be. That's why the submission rate measurements are so important. On 7/8/2014 12:23 PM, Justin Dolske wrote: 3) E10S will already need something vaguely like this, since a content-process crash won't take down the whole browser. (And having the native crash report pop up would be weird.) I'm not sure if we know what the content-vs-chrome breakdown will be for all crashes with E10S, but I'd sorta assume content crashes would be more common, and that UX flow will be the one seen more frequently by users. Content-process crashes will be similar to how plugin crashes currently work, and crash submission will be handled in-frame. To the extent that crashes are caused by memory or other similar issues, we do expect most crashes to be in content processes; but there's the whole class of crashes which are caused by Firefox extensions/other 3rd-party software/malware which are likely to remain in the base Firefox (chrome) process. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Firefox/Thunderbird and GRE/XRE/XULRunner
On 7/8/2014 2:51 PM, Tobias Besemer wrote: As far as I can remember, at the beginning when GRE was build, there was the try that Firefox/Thunderbird/Mozilla-Suite will use this ... After Thunderbird is now back, a Mozilla Update Service exist and the Crash Reporter needs to be re-done, but keeps a standalone App for startup problems of Firefox/Thunderbird ... Is there a chance, that Firefox Thunderbird will share files (runtime environment / framework) together again on Windows ??? No. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Unit testing internal JS
On 7/7/2014 1:53 PM, Josh Matthews wrote: Garvan is referring to JS files that implement XPCOM interfaces. It's impossible to test internal details of the components without exposing them via an interface, which can end up convoluting the code in some cases. I expect you can import them using Cu.import if you wanted just for testing. You might need to use an unusual import name like resource://gre/components/nsSomething.js. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Guidelines for naming preferences?
On 6/30/2014 9:53 AM, Masayuki Nakano wrote: On 2014/06/30 22:51, Masayuki Nakano wrote: Hi, I wrote a draft of the guideline in MDN roughly. I hope a lot of developers discuss the rules and improve this draft! Oops, the draft is here. Sorry for the spam. https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Preferences Thanks for starting this. I've made some significant modifications: * Added a list of situations where prefs should or shouldn't be used * Removed the list of toplevel pref roots. I don't think this list is valuable, and I don't think that adding new roots is necessarily bad. * I don't believe there's a good case for preferences that are read but don't appear in the default pref files. I have changed the recommendation to always add a default value * Clarified where default prefs belong: prefs that are read by gecko belong in all.js, but Firefox-specific prefs belong in firefox.js --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Guidelines for naming preferences?
On 6/19/2014 10:00 PM, Masayuki Nakano wrote: I'm looking for guidelines for naming preferences. However, I've never found it yet. I guess that there is no guidelines. That is correct. The current rule is to use common sense and coordinate with the module owner. If the pref will be exposed in the UI preferences, you should also coordinate with UX design to make sure that we can express the preference in the UI in a useful way. When I work on some bugs, I need to add a new option for a pref switchable behavior, e.g., if we need to add a new option to a feature and the new one isn't enabled in default settings, it's better to add new pref for the additional option in some cases. Here are the reasons we should be adding prefs: A. We actually want to expose the option in the preference UI (needs UX review) B. To enable release drivers to turn it off easily if there is a problem found C. a feature is experimental and we want to limit it to certain channels while it is stabilized D. To enable other internal usage: e.g. A/B testing via telemetry experiments I believe that we should not be adding hidden prefs just because a small minority of people might want a feature, but we've decided not to expose it in the browser preferences. Those kinds of choices should be made by installing Firefox extensions. In particular, using an extension instead of a hidden pref setting means that we will see the non-default choice in various metrics like about:support, telemetry/FHR, and that Firefox safe mode reverts the setting in case of problems. In any case, this probably doesn't have much to do with naming ;-) I think that a pref which enables/disables a feature should end with |.enabled|. Then, above example becomes: |foo.a_feature_name.enabled| |foo.a_feature_name.disabled_on_some_environments| If it's a boolean feature, I think the common pattern is to used foo.feature.enabled. e.g. app.update.enabled or dom.ipc.plugins.enabled. This sounds reasonable to document. The can be defined by a formula: general-group.(sub-group.)*target-feature.state The state shouldn't be omitted. I think this rule is too general. Let's stick with the enabled rule for now. And also, sub-group should be used as far as possible. Why? Flat names seem quite reasonable. nsXPLookAndFeel observes every pref. For doing that, it observes *all* prefs under |ui.|. http://mxr.mozilla.org/mozilla-central/source/widget/xpwidgets/nsXPLookAndFeel.cpp#430 And the observer uses 3 loops for retrieving the pref cache from the arrays. http://mxr.mozilla.org/mozilla-central/source/widget/xpwidgets/nsXPLookAndFeel.cpp#388 If somebody changes a pref under |ui.| at runtime, every change causes running this expensive method. How expensive? Pref changes at runtime are in quite unusual after startup, and I don't think we should necessarily optimize for this case. On the other hand, I do think it makes sense to consider the implementation when defining a pref namespace: if you're observing an overly broad branch and there's an easy way to design that away, that sounds reasonable. For example, some metrics/colors which can be retrieved with LookAndFeel class can be override by hidden prefs. The most hidden prefs are named as |ui.metricsName| or |ui.colorName|. http://mxr.mozilla.org/mozilla-central/source/widget/xpwidgets/nsXPLookAndFeel.cpp#26 # Anyway, if it's allowed, we should rename the pref names referred from nxXPLookAndFeel even though customized users will need to set them again. Do we need this code at all? This sounds like the kind of code that would be better to remove entirely. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Telemetry now enabled by default in the beta channel of Firefox desktop and Android
With the 31 train going to beta last week, Firefox telemetry is now enabled by default for new and existing beta users for Firefox desktop and Firefox for Android. Existing users will see the data-choices prompt again. The beta population in particular is much more representative of our release users than the nightly or aurora populations. It has a range of locales, extensions and plugins, and usage patterns which makes it possible to predict how a feature or change will affect a release population which doesn't work on nightly/aurora. Our large, active, and engaged prerelease users are an advantage to Mozilla. Our intention is to use the Firefox beta population much more actively to measure aspects of the browser, both existing and planned. This includes built-in measurements as well as the experiment system. I encourage everyone who is building Firefox code to consider whether there are measurements or experiments that would help you make better decisions about upcoming features. If you are unsure about a potential measurement or experiment, I am available as a guide. I am happy to help design experiments to produce useful answers while still honoring our prerelease users' privacy and security. Please followup to dev.planning if you have questions or comments. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
New crash signatures for out-of-memory crashes: OOM | ...
Starting yesterday, you will see new crash signatures for out-of-memory crashes in crash-stats. The changes were implemented in bug 1007530, but here's the summary: OOM crashes are divided into three groups: known-small, known-large, and unknown-size. The known-small crashes will all have a signature of OOM | Small. The engineering action for these crashes is to figure out why we're running out of memory and solve that problem. The specific stack trace is in general not interesting. A small allocation is 256k or smaller. The known-large crashes will have a siganture of OOM | Large | C++Signature. The engineering action for these crashes should typically be to make the call site use a fallible allocator instead of an infallible allocator. Crashkill will track and file the most common versions of these as part of crashkill. The unknown-size crashes don't have an OOMAllocationSize annotation. In this case, the engineering action is to make sure that these crashes end up with an annotation so that we know whether they are large or small. Crashkill will file and track these as appropriate. In gecko code the NS_ABORT_OOM function can be used to do this annotation. A crash is considered an OOM crash if the OOMAllocationSize annotation is present, or if the signature contains any of the following: NS_ABORT_OOM, mozalloc_handle_oom, CrashAtUnhandlableOOM. It is likely that we will add additional signatures or conditions to this list as we discover them. Please followup to dev-platform with questions or concerns. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: API propose to public place.
On 6/17/2014 10:58 AM, luoyongg...@gmail.com wrote: At the current time, there is four function can not be accessed outside but required. You may file a bug and attach a patch for these if you wish. I presume the code you pasted below would go in nsStringAPI.h but all patches and reviews are handled in bugzilla.mozilla.org. Product Core component String. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: xpcom supported
On 6/2/14, 2:38 PM, savani1ama...@gmail.com wrote: developing .so / dylib / .dll using xulrunner sdk and then calling it in extension in javascript is that still supported. i see very poor documentation on the web on it. and no good working example. Savani, you have posted variants of this same question to three different lists within the past hour. Please be patient when you ask questions and try to avoid list-hopping. Please direct followup replied to mozilla.dev.extensions. i am developing a c++ component using xpcom. i could develop an .so file using xulrunner-sdk. however xpcom viewer doesnt recognize my component. so basically something wrong in manifest file or rdf.. how to debug this? .so file seems to be in correct format .. i mean i started using it in c program and it asks for nsisupport. so i am assuming .so file is not corrupted or anything.( just thought i should check that out first) The best tool for this is the browser console. 1) Check and see whether there are any messages related to component registration. I've tried to add comprehensive error reporting to the registration code. 2) Check for the presence of your contract: Components.classes[@whatever/my-component;1] 3) Try to create the component: Components.classes[@whatever/my-component;1].createInstance(); 4) If you added a new interface, test for it: Components.interfaces.nsIMyInterface; 4) Try to create the component using your new interface: Components.classes[@whatever/my-component;1].createInstance(Components.interfaces.nsIMyInterface); can someone confirm latest xulrunner sdk supports and an extension can be developed using c++ xpcom. Compiled components are supposed to work, yes. Several addon authors are still using them. However, they are strongly discouraged and we may decide to remove support for them in a future version of Firefox. You're encouraged to write your addon entirely in JavaScript if possible; if you must interface with external binary code, please consider loading a binary shim using JS-ctypes. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: OMTC on Windows
On 5/18/2014 3:16 AM, Bas Schouten wrote: remove a lot of code that we've currently been duplicating. Furthermore it puts us on track for enabling other features on desktop like APZ, off main thread animations and other improvements. What is APZ? Is OMTC turned on in all graphics setups, accelerated and not? Are we testing browser performance/responsiveness in these setups? There's several bugs still open (some more serious than others) which we will be addressing in the coming weeks, hopefully before the merge to Aurora. I want to call out one specifically, bug 933733 (and related bug 912521) which we know is going to regress; we currently don't know how to fix and we're not sure why it's happening. If anyone experiences the Firefox UI freezing unless they are moving the mouse, please let us know ASAP in the bug and we'll work with you to collect trace logs and try and pinpoint a solution. - Memory numbers will increase somewhat, this is unavoidable, there's several steps which have to be taken when doing off main thread compositing (like double-buffering), which inherently use more memory. I am concerned about this in general, because we know that OOM is a real problem for many of our users currently, and we have very poor metrics on memory usage in the wild. So I have a couple questions: * Is it a fair statement to say that the primary benefit of OMTC is in browser responsiveness and jank? * Are there settings/knobs which which can reduce the memory usage of this feature (other than disabling OMTC completely)? If so, do we have a plan for tuning those knobs on beta before this hits release? * How will we know whether OMTC is a net win for users on low-memory computers, where increased memory usage and paging might offset the responsiveness benefits? * Are there accurate about:memory reporters for OMTC buffers? --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Gecko style: Braces with enums and uninons
On 5/18/2014 11:16 PM, Dave Hylands wrote: My interpretation of this is that the only time braces go on the end of the line is when you're starting a control structure https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Control_Structures structs, enums, classes, and functions are not control structures, so the opening brace should be at the appropriate indentation level on a line of its own. I agree with this interpretation. Please feel free to clarify the style guide if there is an obvious way to do so. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Adding a recommendation that one-argument constructors be explicit to the C++ style guide
On 5/12/2014 4:07 PM, Boris Zbarsky wrote: So I'd like to propose that our C++ style require one-arg constructors to be marked explicit unless there's a clear comment explaining why the constructor is implicit. Seems there's general agreement. Please make this change to the style guide. Anyone here up for doing some static analysis to detect and fix in-tree instances of this? --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Media Source Extensions
On 5/7/2014 2:36 AM, Matthew Gregan wrote: Summary: This specification extends HTMLMediaElement to allow JavaScript to generate media streams for playback. Allowing JavaScript to generate streams facilitates a variety of use cases like adaptive streaming and time shifting live streams. I fully support this; since the web lacks a standardized adaptive-streaming mechanism, doing this in JS is a good stopgap. Although I do think we should continue to try and build a standardized adaptive-streaming mechanism. Do we have plans for an API that lets users record the video data that is sent to the browser via MSE? Video-downloading is a very common Firefox addons, and I believe that just as users can download video src= we should continue to provide users with the ability to save videos even when they are delivered via MSE. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Is there any method i can use to kill child process after killing parent process in Js
On 5/1/2014 9:24 PM, zero wrote: i fork a process from his parent process using nsIProcess.runAsync() when i kill the parent process , the child process is untraceable. is there any method i can use to kill child process after killing parent process This is a hard problem in general. On Windows, you may be able to put everything in a Job and then kill off the job if you don't need it any more. On *nix systems a process group can do approximately the same thing. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Telemetry experiments now in nightly
Telemetry experiments is enabled as of this morning's Nightly. Our first experiment is already live: it reorders the tiles in about:newtab so that the most-frecent tile is in the center instead of the top-left. The experiment should deploy to 25% of nightly users for a 5-day period from now through 15-May. Users who have DOM inspector or tree-style-tabs active will not receive this experiment. This experiment is mainly deployed to check that the experiment system and experiment conditions are working correctly. To see a list of current and past experiments, visit https://telemetry-experiment.cdn.mozilla.net/ If you have experiments that you'd like to run, either now on nightly or on other channels as this rides the trains, please email me or file a bug in Firefox:General and cc me. Questions/comments/replies to firefox-dev please. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Can we remove NS_HIDDEN, NS_HIDDEN_(...)?
On 4/22/2014 7:31 AM, Robert O'Callahan wrote: It's all over the tree, inconsistently applied. Is it relevant anymore? Can we remove it entirely, or there some places where it's still relevant, and if so, where ... XPCOM? Or should we be using it everywhere? Short answer: I don't think it's relevant any more. Long answer: Each compiler and platform is a little different, so here's my take on where we are: * Windows/MSVC. NS_HIDDEN never had any effect; symbols are hidden by default and need dllexport to be exported * Mac/GCC or clang. We compile with -fvisibility=hidden. This means that all symbols are hidden by default and you need NS_EXPORT to mark them as exported/dynamic. Declarations are treated as dynamic. However because Mach-O executables use direct relocations, there is no actual difference between the generated code referencing a hidden or dynamic symbol, so we're fine. * Linux/GCC or clang. We compile with #pragma visibility. This means that all symbols and declarations are treated as hidden by default and require NS_EXPORT if they are exported/dynamic. I believe that we're also using #pragma visibility on Android and B2G, but somebody should probably check. We should be! --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removing [PID] prefix from |make mozmill| warning/error/assertion lines?
On 4/18/2014 7:07 PM, ISHIKAWA,chiaki wrote: Does anyone know how to disable this prefixing short of modifying the source code? Why can't you just accept this in your parsing regex? There is no runtime control for this behavior. It was made non-optional so that we could which process an assertion was coming from when child processes are present (plugins, content, eventually sandboxed media decoders). http://hg.mozilla.org/mozilla-central/annotate/db431ea44a1a/xpcom/base/nsDebugImpl.cpp#l311 --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement: Web Activities for Android
On 4/16/2014 12:37 PM, Wes Johnston wrote: Something like this is needed for integration of B2G WebApps on Android. Without it, they have no way of talking to one another, let alone any way of talking to Native Apps. The best they can provide is launching a uri with a specific scheme and to hope something on the other end is able to pick it up. There's also no way to get a return value from that app. I don't think we can provide a compelling experience there without providing something like this. We're planning to hold this to non-release builds for now though. When you say intent to implement what is it you're planning on implementing? * web activities between b2g-style webapps on Android * web activities called by sites loaded in the Firefox for Android browser? * web activities provided by sites loaded in the Firefox for Android browser? * webapps can call into native apps via web activities APIs (e.g. sharing-native twitter)? * webapps exposing intents to native Android apps via activities? Intents do seem like a pretty fundamental part of an app ecosystem, but there seems to be a big disconnect between the stated intent to implementing them for Android and yet having no clear plan to standardize them. I strongly feel we shouldn't ship this (to release users on Android/desktop) until we have a stable spec. What's the point of implementing this if we don't also have plans to standardize and ship it? --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship navigator.sendBeacon
On 4/16/2014 2:18 PM, Richard Barnes wrote: I don't know about problematic, but ISTM that it might be useless. If people disable sendBeacon in an effort to avoid tracking, then the trackers can always just test and polyfill with XHR. If you really want disable tracking, you're going to have to do a lot more, and probably break a lot of the web. Oh, I figured the pref flip would leave the sendBeacon API visible, it just wouldn't *do* anything. That would be a lot more effective than completely hiding it. This is very similar to the discussion about a ping. Can we enhance privacy for the users who care a lot by implementing the ping, getting sites to stop using redirectors for metrics, and allowing some users to disable the ping? --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MOZ_ASSUME_UNREACHABLE is being misused
On 4/1/2014 10:54 AM, Benoit Jacob wrote: Let's see if we can wrap up this conversation soon now. How about: MOZ_MAKE_COMPILER_BELIEVE_IS_UNREACHABLE I counter-propose that we remove the macro entirely. I don't believe that the potential performance benefits we've identified are worth the risk. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MOZ_ASSUME_UNREACHABLE is being misused
On 4/1/14 5:37 PM, Karl Tomlinson wrote: Karl Tomlinson writes: However, I would like to discourage use of MOZ_CRASH in future code unless failure to match cases in a switch is really more scary than crashing. I think in general we should be willing to make more of our assertions fatal in release builds, especially in non-performance-sensitive code. Of course the choice of assertion depends on the characteristics of what's being asserted. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Firefox build (Nightly) thread with root permission
On 3/31/14 4:56 AM, Paul wrote: Q1: Because my function is related to kernel, root privilege is necessary. Hence, I got the error message as shown in the following: root privileges needed to run this function--- What function are you talking about? Something in Firefox already, or new code that you are adding? Q2: By running the function with sudo sudo ./mach run Things seem running well. However, the browser can not be launched and it ended without any notice. Firefox is not meant to run with root privileges, and I actually thought we checked and refused to launch in that case. I can't find the bug about it now, though. In any case I strongly discourage running Firefox as root. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Too many system compartments at start-up
On 3/21/2014 2:46 AM, Nicholas Nethercote wrote: Hi, At start-up, with a new profile, Firefox creates more than 230 system compartments. This is about 90 more than a year ago, and it's part of the reason why Firefox uses almost twice as much physical memory at start-up than it did two years ago. (Have a look at https://areweslimyet.com/ for the measurements.) What is the per-compartment overhead? It seems like we have two possible solutions in general: * stop doing so much at startup/make sure feature code is only loaded when the feature is used * combine things that are currently in multiple compartments together into one compartment. Perhaps some manual combination of .jsms into a smaller number of compartments similar to what B2G does? I recently filed bug 982623 which might be able to help somewhat. Currently many frontend features are primarily written as a .jsm, but have a separate XPCOM component so that they can register for startup/profile/update-timer notifications. With that patch we should at least be able to get rid of the separate XPCOM component and only use the .jsm. I suspect that you'll have more luck if you direct questions or recommendations to specific module owners/teams based on this list. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Too many system compartments at start-up
On 3/21/2014 10:34 AM, Marco Bonardo wrote: Or directly make Cu.import act like defineLazyModuleGetter... Would that be possible? I don't think that's a good idea. It's not an uncommon pattern to try/catch around a module import in case it's not present in a particular configuration or the expected symbols aren't exported, especially when writing addons that cross versions. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Please do not add new web-exposed XPCOM objects
On 3/14/2014 11:26 PM, Boris Zbarsky wrote:
For non-core, if you control the Gecko you build against, then the
answer is the same. If you have to work against a random Gecko,
that's a problem we don't have a good solution for yet.
Assuming you really need to expose the object to a web page. On the
other hand, it's not clear to me that you want to be exposing objects
to all web pages like that, in general.
Isn't this something which pagemod addons and greasemonkey already do?
There's clearly lots of use-cases for polyfills or experiments provided
by addons. Do we not have a safe way now to expose objects and functions
to pages (all pages or some pages)?
I did discover recently that you can expose properties on the global of
a Cu.Sandbox, but only the global, and you can't expose deep object
hierarchies. There are also scary warnings about using return results
from an .evalInSandbox on this doc page, which seem like footguns still:
https://developer.mozilla.org/en-US/docs/Components.utils.evalInSandbox
For my case, I wasn't calling into the DOM, I was calling into a
null-principal sandbox, but the sandbox was basically supposed to define
a function:
// Filter for whether to run a telemetry experiment
function filter(context) {
if (inspec...@mozilla.org in
context.healthReportPayload.data.last.org.mozilla.addons.addons) {
return false;
}
return true;
}
And then I would call the Sandbox.filter function with a context object
that has the FHR payload. But since you can't pass complex objects to a
sandbox, I've had to serialize the structure using JSON and deserialize
it in the sandbox. Maybe this means we should consider exposing some
kind of structured-clone system for calling untrusted code, plus a safer
way to call functions which may return arbitrary results?
--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Using preferences off the main thread now asserts
On 3/6/2014 4:05 PM, Benoit Girard wrote: Thanks for doing this. However I feel like our options for code that need preferences off the main thread are a bit poor. Yes. This is mostly intentional, because it's unusual to actually have user preferences affect threaded code behavior in ways that don't require knowledge of and cooperation from the main thread. What is the use case where you need this? The first option is to send an IPC message to the main thread but that has very poor performance, requires a lot of boilerplate code and either an sync message or async+restructuring the control flow. The second option is to read the preferences on startup and have them as read-only shared globals like gfxPrefs: http://mxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxPrefs.h#106 The third option is to use pref observers and a lock to save the state of a pref in a protected variable. For cases where you actually want to honor runtime changes, this makes the most sense. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Plugin whitelist
On Friday Chad posted and blogged about our proposed plugin whitelisting policy. https://wiki.mozilla.org/Plugins/Firefox_Whitelist https://blog.mozilla.org/security/2014/02/28/update-on-plugin-activation/ The primary goal of this policy is to give plugin vendors who are working on moving towards HTML5 solution some additional time to make the transition, as well as providing feedback from plugin vendors to our web API teams about features missing from the web platform. We will continue to preserve user security by keeping engineering and QA contacts for each plugin vendor. Please ask questions/provide feedback by replying to mozilla.dev.tech.plugins. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Including Adobe CMaps
On 2/26/2014 4:36 PM, Bobby Holley wrote: On Wed, Feb 26, 2014 at 12:58 PM, Wesley Hardman whardma...@gmail.comwrote: It seems like it would be trivial to add a button in the Preferences UI to let people precache all dynamically-loaded data. I don't think that would be trivial. In particular, which spellchecking dictionaries would we download? All hundreds of them? Typically people are only ever going to use one or a few. The different kinds of data here may need different defaults. I think this whole thing is valuable, but it's going to require some significant thought about how we manage this data and probably a whole new release mechanism for updating the data if necessary. If we did decide to automatically stream-download some or all of the data for desktop builds after the initial install, that might nullify the cost savings associated with reducing the initial download size. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: mochitest logging changes
On 2/27/2014 10:00 AM, Nathan Froyd wrote: - If there is a TEST-FAIL or a TEST-UNEXPECTED-PASS, then the failure itself is logged, along with some number of messages (currently capped at 100) since the start of the test or the last failure. The intent here was to provide most of the benefits of suppressing messages while still showing some record of what the test was doing prior to the failure. Is there a reason why it's not every message since the start of the current test or the 100 most recent, whichever is greater? I imagine that seeing the entire output of the single test that failed might be useful in many circumstances. - If you run a single test locally, then all the messages produced by the test will be shown. Is there a mach flag which can force full logging of an entire run whether it's a single test or an entire directory/manifest? --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Including Adobe CMaps
On 2/26/2014 3:21 PM, Jonathan Kew wrote: On 26/2/14 19:57, Andreas Gal wrote: Lets turn this question around. If we had an on-demand way to load stuff like this, what else would we want to load on demand? A few examples: Spell-checking dictionaries Hyphenation tables Fonts for additional scripts Yes! Also maybe ICU data tables, although the current web-facing APIs don't support asynchronous download very well. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Platform SDK: What do we really want it to be?
On 2/6/2014 2:08 AM, ajvinc...@gmail.com wrote: I recently submitted a bug and patch to copy the stub executable and application bundling script (install_app.py) from XULRunner to Firefox. Mike Hommey (glandium) thinks that's a bad idea. [2] His objection is that that just makes it stay outdated each time browser/app/nsBrowserApp.cpp is changed, which is one of the many reasons we want to get rid of xulrunner. It's clear that we need a stub executable to run apps. The question at hand is whether firefox.exe can be that executable or whether we need a different one. Third, a Owners' Vote section where a group of contributors vote yea or nay on the second section as it stands on the date they last read it. Specific objections and commentary may be written afterward. Also, constructive edits anywhere in the document (in particular, clarifying requirements or adding important requirements that I missed) are welcome. The idea is to arrive at a clear consensus on requirements. glandium and I are the owners in terms of Mozilla module ownership. While I certainly don't mind this relatively formal process of collecting various requirements, I think that it might be just as useful to start with what we have: an SDK which primarily supports Firefox addon authors who are compiling binary components. Then progressively add and subtract features until we have whatever solves other needs. As for delivery dates on the actual Firefox Platform SDK: I don't know. The core requirements are pretty simple: * Firefox addon authors need to be able to use it to compile binary XPCOM components * It needs to be built as part of the Firefox build and shipped with the first beta of a release It seems that this is perfectly achievable in the 30 timeframe, and we can add more pieces later as people are available to do the work. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
WebAudio popping
Not sure if there's a better group to ask about WebAudio stuff
specifically. Is there a way to keep WebAudio from popping when I
start/stop an oscillator or change gain? The WebAudio spec claims that
changes in gain should be dezippered to avoid popping, but that doesn't
seem to happen in practice. e.g. this kind of script is popping a lot
for me on mac:
var gAudio = new AudioContext();
var gGain = gAudio.createGain();
gGain.gain.value = 0;
gGain.connect(gAudio.destination);
var gOscillator = gAudio.createOscillator();
gOscillator.frequency.value = 256;
gOscillator.connect(gGain);
gOscillator.start(0);
function toggleGain()
{
if (gGain.gain.value == 0) {
gGain.gain.value = 1;
}
else {
gGain.gain.value = 0;
}
}
setInterval(toggleGain, 400);
Also, is there a minimum frequency for an oscillator? It seems like I
don't get any audible output for sine-wafe frequencies below 115 or so
and square-wave frequencies below 55 or so, when both piano and human
hearing go down to 25hz or so.
--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: A proposal to reduce the number of styles in Mozilla code
On 1/30/2014 7:25 PM, Nicholas Nethercote wrote: One of my primary goals with starting this discussion was to reach agreement that mass style fixes (e.g. covering entire files) are acceptable. I agree. We should focus our efforts on converting whole files of code to our new style and then enforcing consistency. entire file (or files) at a time. (And if we're going to fix indentation, obviously we should fix any other style problems at the same time.) I'm not sure that we need to fix all the problems in order to be useful. I'd certainly automatically-generated whole-file patches which just do re-indenting and some simple brace fixup. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: A proposal to reduce the number of styles in Mozilla code
On 1/27/2014 7:08 PM, Nicholas Nethercote wrote: It's been a couple of weeks now. Can we move forward? Anthony Jones has done some work on using clang-format to restyle lines that have changed in a file, but I don't think anyone has done any evaluation of clang-format for whole-file changes. I wonder if we could allow hand-reformatting (e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=956199), at least for the moment? Because if we don't allow that, we're stuck in limbo until we decide on official guidelines for using automatic tools. Modules owners can *allow* hand reformatting to the style guide any time they want. I don't want to encourage that in the style guide, though. I would encourage people, rather than doing hand reformatting, to run the clang-format tool on an entire file and identify with the module owner whether it produced useful results. There are still some cases that will need to be fixed by hand after (the CC macros especially). That's the only way we're going to get feedback on clang-format anyway, right? --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Telemetry Experiments: experiment, A/B, and questionnaire implementation in Firefox
One of the things I have been looking at in some detail recently is how we can use qualitative measurements in Firefox. This includes better integration of existing Telemetry and FHR systems, but also measurements which don't fit into those systems. Part of my study was prompted by a request from Mozilla user research, who want to be able to run experiments and collect data from Firefox users, in a similar way to the mostly-defunct Test Pilot program, but with a better sample population and more rigorous engineering and release. I also collected examples of problems that various groups have wanted to solve using data collection. It turns out that some of these use cases can already be solved using existing deployment and measurement systems, while others need additional features. https://docs.google.com/document/d/19qPbV8XJQL0bDwG4ZOfFhIdwbeFAM-5VT9S8uCpzapc/edit?usp=sharing I'm interested to know whether there are other important cases which a significantly different from the ones which I've already collected. In particular, I'm looking at the following variables: * User population: what kind of user population is desirable/necessary in order to answer the question? For an early-stage UI demo, the desired population may be users who want to live on the bleeding edge and are willing to live with bugs. For some studies, we may want to examine user behavior in particular countries or who have particular addons installed. * Data privacy characteristics: in order to answer the question, do we need to collect any identifying information, such as URLs? Does collecting the data provide direct benefit back to users? * Engineering: does the measurement require changing core code, or can the measurement be implemented as addon code? What is the expected quality of the change being considered? * Result monitoring: what kind of result monitoring is necessary? Do we expect a single report to run after a while, or will this measure ongoing Firefox behavior? Is it important to be able to correlate results against other pieces of data? * User interactions: to what extent should users be aware that a measurement or experiment is in progress? Do we want to ask them specific questions or does the experiment require some sort of opt-in or opt-out (this is related to the questions about privacy and user population). This quarter (in Firefox 30) my team is going to focus on building out one specific system, a way to deploy experiment code to prerelease users in Firefox desktop builds. We're going to start out small, solving a specific request from Gregg Lind in user research for a tool to deploy some experiments related to search behavior in Firefox. https://docs.google.com/document/d/1GPpkIcWFNkZmXONjqBCc05U3uocOD-1jpZHdAsR0v1k/edit?usp=sharing Each experiment will be deployed as a restartless addon, and measurements will be taken via some combination of existing FHR and telemetry data collection channels. The experiment system will be limited to people with telemetry enabled(1) and each experiment will also be able to set additional conditions, such as limiting the experiment to users in certain release channels, locales, addons or lack of addons, etc. After this first phase is complete, I expect to extend this system. We will probably want to be able to run similar experiments in Firefox for Android, although addons can do far less UI modification in general. We will also want to handle A/B testing where we don't install an addon, but simply flip various pref configurations. We also plan on extending this same system as a way to deploy questionnaires or surveys to users. For example, if we find an addon which appears to be malware, we might ask users whether they know the addon is installed, whether they installed it intentionally, etc. I am interested if people have specific high-priority studies or surveys in mind that we can use to serve as models for future revisions. Finally, we are considering whether and how to combine FHR and telemetry data collection. Each system currently has weaknesses which we'd like to address, and it seems that the best way forward is to combine them. This is still in early decision-making, but I've written up a proposal here for comment: https://docs.google.com/document/d/1JKnqejahVWMev4xUYGbRiICw0HpwopcXBqPYxco0YzU/edit?usp=sharing Questions, concerns? Followup to firefox-dev please. --BDS 1. Currently telemetry is enabled by default in nightly and aurora builds, and I have requested that it be enabled by default in all prerelease builds (including beta). Being able to run experiments on beta users and measure the results is critical, since our beta user population is much more representative of release users. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Exact rooting is now enabled on desktop
On 1/17/2014 4:24 PM, Terrence Cole wrote: Exact stack rooting is now enabled by default on desktop builds of firefox. Does this mean that the moving GC is also enabled, or is that a later step? If we see an increase in the crash rate for nightly builds, is it likely that they will share a signature, or will this mainly expose itself as memory corruption, which typically don't have useful crash stacks/signatures? Are there ways for users who are seeing crashes to turn on extra debugging (memory poisoning in the GC, for example) in order to make crashes more reliable? The stability team will be watching crash-stats closely over the next week. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
On 1/14/2014 2:30 PM, mka...@gmail.com wrote: On Tuesday, January 14, 2014 1:06:19 PM UTC-6, Benjamin Smedberg wrote: Or do a repack to remove the Firefox-specific files from a Firefox install. Certainly without branding issues it's not a problem anyway, right? So in my testing, this worked perfectly. If we could solve the stub problem, I don't see why this can't be a perfect replacement for xulrunner. I don't think we need to solve the stub problem to implement this plan; I'll take patches which compile a generic stub into the SDK. firefox.exe is after basically the stub already with embedded icons and whatnot. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
On 1/14/2014 3:17 PM, ajvinc...@gmail.com wrote: I'd like to get a clarified list of requirements for the Firefox SDK: * Will we support a stub executable? If somebody writes a patch to include a stub executable in the SDK, I will accept that patch. If you include automated tests for it, I'll count that as a form of support. But if it breaks, we wouldn't close the tree or block the release on it. * Will we support an install-app capability in the SDK? If you want to include those scripts in the SDK, I'll review it. * Will Mac SDK users be able to create .app files that actually work? I don't know. If somebody does the work, sure! * Will they have a XUL.framework in them? Probably not. * Will we still publish headers, binary tools, etc. in a convenient package for component developers to use? We will continue to publish the SDK. * Can we import Philipp Kewisch's wonderful remote debugger extension, so that Firefox can remotely debug the XULRunner app? (By the way, that works in XR apps now.) Maybe? * Will we have automated regression tests run daily to make sure the SDK is still viable? Probably not. Even if somebody wrote the test framework, this is low priority compared with other tasks that automation or releng have. * Can we get everything in place and make an ESR SDK as well? I don't think it matters. The SDK isn't supposed to change between security dot releases, so typically you wouldn't need a new one; you'd just keep using the base version for the life of the ESR release. But at the same time, if the SDK is a byproduct of the Firefox build, we'll get it for free with the Firefox ESR builds. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
On 1/12/2014 7:34 PM, Mike Hommey wrote: Hi, I propose that we just stop pretending, and terminate xulrunner, considering the following: This has in fact been the plan for a while now. The only reason we continue to do any regular XULRunner builds at all is because we do need to publish an SDK, and currently the Firefox build does not produce a SDK as a build product. As soon as somebody fixes bug 672509 and we get releng to deploy that, we can turn of the XULRunner builds. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Style guide clarity on C++-isms
On 1/13/2014 2:33 PM, Milan Sreckovic wrote:
I didn't mean no inlining :), I was just talking about the format:
class A
{
public:
inline int hello {
return 4;
}
};
vs.
class A
{
public:
inline int hello();
};
inline int A::hello()
{
return 4;
}
We're pretty far from the original discussion. We aren't going to moving
method bodies as part of this initial reformatting effort, so for C++
method bodies which are inline in the class, let's go with Ehsan's
strict style rules:
Method
{ // Must be on the next line
} // Must be on the following line
We can have a separate discussion about whether moving methods below the
class declaration is a good idea.
--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Sharing string literals
On 1/10/2014 12:19 AM, Daniel Holbert wrote: Just to be clear -- does this mean we should strictly prefer str.Assign(NS_LITERAL_STRING(foo)) over str.AssignLiteral(foo) now? For wide strings, I'm pretty sure the pattern we want is AssignLiteral(MOZ_UTF16(foo)). And as Henri mentioned, we probably want to remove the char version once that happens. We'll be filing followups once we're sure this sticks. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Please use NS_WARN_IF instead of NS_ENSURE_SUCCESS
On 1/6/2014 7:43 PM, smaug wrote: Why this deprecation? Karl is right, we are removing the macros that hide control flow (as well as warnings, in this case). I'm considering the NS_WARN_IF_FAILED(rv) proposal. It's obviously a less typing then NS_WARN_IF(NS_FAILED(rv)), but I'm not convinced that it's clear just by reading it what the return type would be, especially since the signature of NS_WARN_IF returns the same value that is passed in: bool NS_WARN_IF(bool); I'm trying to figure out if people would expect the result of NS_WARN_IF_FAILED to be an nsresult or a bool. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: A proposal to reduce the number of styles in Mozilla code
On 1/5/2014 9:34 PM, Nicholas Nethercote wrote: I propose that we officially remove this implicit discouragement, and even encourage changes that convert non-Mozilla-style code to Mozilla-style (with some exceptions; see below). When modifying badly-styled code, following existing style is still probably best. I don't think that style changes are currently actively forbidden, but they aren't exactly encouraged. What you're primarily changing is whether they are encouraged. I think that there are two important rules here: * Real patches shouldn't mess with coding style * Style changes should be coordinated with the module owner to minimize conflicts with other patches that are in progress or planned. Karl suggests in the thread that we should discourage reformatting which moves code to a different line, which would appear to include braces. I disagree, since bracing changes and whitespace formatting are the most important issues for scanning code, and we should fix them all at once. What's not clear to me from the discussion is whether there is a reformatting tool which already exists which can do what we need. If there is, I think we should actively discourage people reformatting by hand, and just encourage people to use the tool at an appropriate time. - There is an semi-official policy that the owner of a module can dictate its style. Examples: SpiderMonkey, Storage, MFBT. Spidermonkey is hard because it uses a different member naming convention and so the changes are potentially much more invasive. But I at least support starting out by unifying the indentation and bracing styles across the tree, and removing other exceptions. Also, we probably shouldn't change the style of imported third-party code; Yes. I am the owner of at least the C/C++ portions of the style guide; I propose to wait and see whether the C++ reformatting tools are of sufficient quality that we can use them directly, to avoid hand-reformatting, and make a final decision next week sometime. In the meantime, we should wrap up the pending discussions about other changes to the style guide, such as 80/100/infinite columns, member/parameter/local naming convention, and other threads that Gavin was going to start and one I'm going to start now ;-) --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Style guide clarity on C++-isms
There are a few C++-isms which vary widely across the tree and I'd like
to clarify before we start any major refactorings.
1) Bracing of method bodies in a C++ class declaration
Currently, C++ method bodies inline within a class declaration are
documented to start on the next line, e.g.
class B
{
public:
void Method()
{
// Inline body brace is on the next line, column 2
}
};
Mozilla code widely puts the opening bracde of inline bodies such as
this on the end of the declaration line, and I want to make sure we're
in agreement to fix this.
2) indentation of visibility within a class declaration
In the above example, public is at the same indentation level as the
class. This is common in new code, but I want to call it out.
3) placement of the colon and commas for C++ member initializers
MyClass::MyClass()
: mMember1(foo)
, mMember2(foo)
{
// function body
}
Existing usage is all over the place. I personally have found this style
to produce the least number of merge conflicts when applying patches to
these kinds of methods, but again I want to make sure we're in agreement.
--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Reacting more strongly to low-memory situations in Firefox 25
= Data and Background = See, as some anecdotal evidence: Bug 930797 is a user who just upgraded to Firefox 25 and is seeing these a lot. dmajor tracked this down to our video implementation creating many threads, each of which has an x86 stack as well as a 1MB memory reservation for the wow64 stack. At the point of the crash, there are 330 threads, which collectively uses about 400MB of address space just for the thread stacks. Many of these threads appear to be created by the Windows media platform code, although there are some Mozilla media threads as well. cpearce is currently looking at this. Bug 937290 is another user who just upgraded to Firefox 25 Nobody is currently helping this user. It doesn't look consistent enough to do easy nightly bisection, unfortunately. There was also a bug which was showing up as an OOM crash but was in fact a a memory corruption issue. == Measurement == * Move minidump collection out of the Firefox process. Turns out this wasn't necessary (although it would still be a good thing to do): dmajor figured out that there was a bug in the code I originally wrote to reserve memory for the crash reporter, and that is now fixed and our empty-dump crash rate is very much reduced. * Develop a tool/instructions for users to profile the VM allocations in their Firefox process. dmajor has some instructions for doing this using xperf at https://etherpad.mozilla.org/sOCISHDFSm which we'll clean up and put in a more permanent home in a bit. It does involve installing xperf and setup and know-how, so it's not something we could give to ordinary users. But for fairly technical users this may be a way to identify issues. * The about:memory patches which add contiguous-vm measurement should probably be uplifted to Fx26, and any other measurement tools that would be valuable diagnostics. This is done, and we also discovered that the breakpad reserved memory was breaking this data so we fixed that in crash-stats also. Also, we now have the ability to use DMD builds on Windows; so in the cases where memory usage shows up in about:memory as heap-unclassified, we can profile the memory usage that way. Huge shout-outs to dmajor, nick nethercote, and Catalin Iacob for making all these tools better! == Graphics Solutions == The issues reported in bug 930797 at least appear to be related to HTML5 video rendering. The STR aren't precise, but it seems that we should try and understand and fix the issue reported by that user. Disabling hardware acceleration does not appear to help. The thread issue mentioned above with video decoding appears to be at least partly to blame for this, but we're not sure how much. == Dealing with OOM crash sites == I am working on generating some reports on existing crashes where OOMAllocationSize is variable, and also crash signatures that correlate highly with OOM conditions. We should fix these sites. These bugs are being filed as blockers of tracking bug 943017: https://bugzilla.mozilla.org/showdependencytree.cgi?id=943017hide_resolved=0 Thanks to Ehsan, Peiyong Lin, and Allessio Placitelli who have fixed several already and are working on a few more. I'll continue to file the most common sites as I discover them. == New Data == With the empty-dump count reduced and the breakpad reservation excluded, I have some new data from nightly builds: https://docs.google.com/spreadsheet/ccc?key=0Ag3-54eJ7D8OdDJSV2xaeEROdjRIM1FzYmdjY1QwclEusp=sharing This is a dump of the Windows crash from this morning which *either* have an OOMAllocationSize annotation indicating that jemalloc couldn't allocate memory, *or* have less than 50MB of contiguous free VM space. The most important columns to track are LargestVirtualBlock, OOMAllocationSize, AvailableVirtualMemory and AvailablePageFile. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Can we start using C++ STL containers in Mozilla code?
On 12/10/2013 9:49 AM, Benoit Jacob wrote: std::set compared to using a hashtable to do the same thing, since AFAIK we don't have a HashSet class in mfbt or xpcom. nsTHashtableKeyType is the XPCOM hashset. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Can we start using C++ STL containers in Mozilla code?
On 12/10/2013 4:28 AM, Chris Pearce wrote: Hi All, Can we start using C++ STL containers like std::set, std::map, std::queue in Mozilla code please? Many of the STL containers are more convenient to use than our equivalents, and more familiar to new contributors. njn already mentioned the memory-reporting issue. Also, some of the containers are not suitable for use in a codebase that doesn't allow exceptions. For instance std::map.at() wouldn't be appropriate in our code and may not compile. AIUI, the current status of using the C++ standard containers is that they aren't necessarily forbidden, but we should be careful about checking our assumptions about how they use exceptions, how much they cost in codesize, and whether we need to reimplement or subclass them in MFBT in order to get better memory reporting. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Should we disable autoplay feature of HTMLMediaElement on mobile?
On 12/8/2013 4:31 AM, Tetsuharu OHZEKI wrote: I welcome your feedback to polish Firefox for mobile and web. Note that autoplay is not the most interesting case, because most of the top video sites don't actually use it; instead they use a scripted .play() call on load. https://bugzilla.mozilla.org/show_bug.cgi?id=944876 may be relevant: in that bug I'm willing to mentor somebody to add a hidden pref for additional control over autoplay behavior. For desktop Firefox, I don't think we'd ever want to disable autoplay *by default* in the foreground tab: many people expect their youtube video to just start if they click the link. I suspect that, as discussed earlier on this thread, it might make a lot of sense to delay starting media in a *background* tab (e.g. opened via middle-click). Then we'd autoplay when the video comes into the foreground. We could even implement a setting where all media pause in a background tab. Before we decide on new defaults, I think we should do some experiments with what we can actually accomplish in bug 944876, hopefully get some prototype extensions out for people to experiment with, and then come back and consider what preferences and defaults it actually makes sense to expose. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
DLLs with missing symbols that make crash signatures less useful
With some recent improvements in crash-stats data[1], we now have the ability to report on which crashes don't have the necessary symbols to produce a useful crash signature. I have generated the following reports from yesterday's crash data: https://crash-analysis.mozilla.com/bsmedberg/missing-symbols.20131208.byname.csv https://crash-analysis.mozilla.com/bsmedberg/missing-symbols.20131208.csv The byname report just looks at which DLL names are missing. The other reports specifically on which DLL versions are missing. Summary: * The out-of-memory issue is causing us not to record symbol information for xul.dll in Firefox 25. This was fixed in Firefox 26[2] * by a large margin graphics drivers are the big problem: Nvidia (nvwgf2um.dll/nvumdshim.dll/nvapi.dll/nvd3dum.dll), Intel (igdumd32.dll/igd10umd32.dll/igd10iumd32.dll) and ATI/AMD (atidxx32.dll/atiumdag.dll). * We are missing some Windows symbols (user32.dll/mf.dll and a few others). These are usually available from the Microsoft symbol server, so I will follow up on this to figure out why they aren't working correctly. * Some probably-malware is showing up: sdata.dll * Some 3rd-party software of dubious quality is showing up: radhslib.dll is Naomi Internet Filter, bug 725503. gbmzh_uni.dll is bug 838568. * Java is npjp2.dll and jvm.dll ... and there's a very long tail Overall, I don't think there is much immediate action we can take to make this better. Long-term, we should continue working with partners such as graphics card vendors to get encrypted symbols for the user-mode drivers. https://developer.mozilla.org/en-US/docs/Crash_Reporting_Guide_for_Firefox_OS_Partners#Upload_Symbols_to_Mozilla has some details about how they can provide Mozilla with encrypted symbols that would improve stackwalking and crash signature analysis. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Reacting more strongly to low-memory situations in Firefox 25
On 11/25/13 8:15 PM, Bas Schouten wrote: I'm a little confused, when I force OOM my firefox build on 64-bit windows it -definitely- goes down before it reaches more than 3GB of working set. Am I missing something here? I think so. I did not mention working set at all. I am merely calculating whether users are running win64 or win32, based on whether they have 4G of total VM size (win64) or 2G/3G (win32). I should highlight something here, caching the last N textures is only occurring in drivers which do -not- map into your address space as far as I have see in my testing. Intel stock drivers seem to map into your address space, but do -not- seem to do any caching. The most likely cause of the OOM here is simply that currently, we keep both the texture, and a RAM copy around of any image in our image cache that has been drawn. This means for users using Direct2D with these drivers an image will use twice as much address space as for users using software rendering. We should probably alter imagelib to discard the RAM copy when having hardware acceleration, and in that case actual address space usage should be the same for users with, and without hardware acceleration. Given that the recent Firefox 25 regression occurs for users whether acceleration is enabled or disabled, I don't think that acceleration is the thing we should be focusing on short-term. But yes, we should continue to measure and correct for VM usage as well as total memory usage in the graphics space. I also suspect that we're not dealing with normal memory usage: it seems clear that we're leaking someting, because the users who are helping figure this out can clearly see issues by loading just a few youtube pages in HTML5 video mode and then refreshing them a few times. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Reacting more strongly to low-memory situations in Firefox 25
In crashkill we have been tracking crashes that occur in low-memory situations for a while. However, we are seeing a troubling uptick of issues in Firefox 23 and then 25. I believe that some people may not be able to use Firefox because of these bugs, and I think that we should be reacting more strongly to diagnose and solve these issues and get any fixes that already exist sent up the trains. Followup to dev-platform, please. = Data and Background = See, as some anecdotal evidence: Bug 930797 is a user who just upgraded to Firefox 25 and is seeing these a lot. Bug 937290 is another user who just upgraded to Firefox 25 and is seeing a bunch of crashes, some of which are empty-dump and some of which are all over the place (maybe OOM crashes). See also a recent thread How to track down why Firefox is crashing so much. in firefox-dev, where two additional users are reporting consistent issues (one mac, one windows). Note that in many cases, the user hasn't actually run out of memory: they have plenty of physical memory and page file available. In most cases they also have enough available VM space! Often, however, this VM space is fragmented to the point where normal allocations (64k jemalloc heap blocks, or several-megabyte graphics or network buffers) cannot be made. Because of work done during the recent tree closure, we now have this measurement in about:memory (on Windows) as vsize-max-contiguous. It is also being computed for Windows crashes on crash-stats for clients that are new enough (win7+). Unfortunately, often when we are out of memory crash reports come back as empty minidumps (because the crash reporter has to allocation memory and/or VM space to create minidumps). We believe that most of the empty-minidump crashes present on crash-stats are in fact also out-of-memory crashes. I've been creating reports about OOM crashes using crash-stats and found some startling data: Looking just at the Windows crashes from last Friday (22-Nov): * probably not OOM: 91565 * probably OOM: 57841 * unknown (not enough data because they are running an old version of Windows that doesn't report VM information in crash reports): 150874 The criterion for probably OOM are: * Has an OOMAnnotationSize marking meaning jemalloc aborted an infallible allocator * Has ABORT: OOM in the app notes meaning XPCOM aborted in infallible string/hashtable/array code * Has 50MB of contiguous free VM space This data seems to indicate that almost 40% of our Firefox crashes are due to OOM conditions. Because one of the long-term possibilities discussed for solving this issue is releasing a 64-bit version of Firefox, I additionally broke down the OOM crashes into users running a 32-bit version of Windows and users running a 64-bit version of Windows: OOM,win64,15744 OOM,win32,42097 I did this by checking the TotalVirtualMemory annotation in the crash report: if it reports 4G of TotalVirtualMemory, then the user has a 64-bit Windows, and if it reports either 2G or 3G, the user is running a 32-bit Windows. So I do not expect that doing Firefox for win64 will help users who are already experiencing memory issues, although it may well help new users and users who are running memory-intensive applications such as games. Scripts for this analysis at https://github.com/mozilla/jydoop/blob/master/scripts/oom-classifier.py if you want to see what it's doing. = Next Steps = As far as I can tell, there are several basic problems that we should be tackling. For now, I'm going to brainstorm some ideas and hope that people will react or take of these items. == Measurement == * Move minidump collection out of the Firefox process. This is something we've been talking about for a while but apparently never filed, so it's now filed as https://bugzilla.mozilla.org/show_bug.cgi?id=942873 * Develop a tool/instructions for users to profile the VM allocations in their Firefox process. We know that many of the existing VM problems are graphics-related, but we're not sure exactly who is making the allocations, and whether they are leaks, cached textures, or other things, and whether it's Firefox code, Windows code, or driver code causing problems. I know dmajor is working on some xperf logging for this, and we should probably try to expand that out into something that we can ask end users who are experiencing problems to run. * The about:memory patches which add contiguous-vm measurement should probably be uplifted to Fx26, and any other measurement tools that would be valuable diagnostics. == VM fragmentation == Bug 941837 identified a bad VM allocation pattern in our JS code which was causing 1MB VM fragmentation. Getting this patch uplifted seems important. But I know that several other things landed as a part of fixing the recent tree closure: has anyone identified whether any of the other patches here could be affecting release users and should be uplifted? == Graphics
Re: Reacting more strongly to low-memory situations in Firefox 25
On 11/25/2013 12:11 PM, Ehsan Akhgari wrote: Do we know how much memory we tend to use during the minidump collection phase? No, we don't. It seems that the Windows code maps all of the DLLs into memory again in order to extract information from them. Does it make sense to try to reserve an address space range large enough for those allocations, and free it up right before trying to collect a crash report to make sure that the crash reporter would not run out of (V)memory in most cases? We already do this with a 12MB reservation, which had no apparent effect (bug 837835). --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Reacting more strongly to low-memory situations in Firefox 25
On 11/25/2013 1:09 PM, Ryan VanderMeulen wrote: So we're clear, this analysis is of 32bit Firefox builds running a 64bit Windows OS, right? So the process is still limited to 4GB of address space. Wouldn't a native 64bit Firefox build have significantly higher address space available to it? This is an analysis of the crash reports from a particular day, so it's almost all going to be 32-bit Firefox because that's the only thing we release. 64-bit Firefox Nightly crashes due to OOM would be lumped into the OOM-win64 bucket in the analysis, but are probably not relevant. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Is for...of on a live DOM node list supposed to do the right thing?
Is for..of on live DOM nodelists supposed to correctly iterate even when items are removed from the list? I have a testcase where this does not seem to be working correctly: http://jsfiddle.net/f8xzQ/ Is there a simple way to do this correctly? --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
