Re: Proposed W3C Charter: Pointer Events Working Group
I think that Mozilla should comment in favor of the PEWG charter. Mozilla has been participating in the WG and it is doing important work for interop and performance of pointer input handling. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Enabling Pointer Events in Firefox (desktop) Nightly
tl;dr: We plan to enable Pointer Events for mouse and pen input in Firefox Nightly builds within the next few weeks. Background: Pointer Events is a W3C recommendation that defines new DOM events for unified handling of mouse, touch, and pen input. It also defines a new 'touch-action' CSS property for declarative control over touch panning and zooming behavior: http://www.w3.org/TR/pointerevents/ The 'touch-action' CSS property is shipping today in both IE11 and Chrome stable. The DOM PointerEvent API is shipping today in IE11, and the Chrome team plans to ship it soon. Status: Implementation of pointer events and 'touch-action' in Gecko has been in progress for several months. Both features can be enabled in Firefox Nightly with prefs, currently off by default. When these prefs are turned on: * Events for mouse input are supported on Windows, Mac, and Linux. * Events for pen input are supported on Windows. * Events for multi-touch input, and the 'touch-action" property, are a work in progress on Windows. These features depend on e10s, and on Async Pan/Zoom (APZ) which is currently preffed off by default on desktop. * PointerEvent and 'touch-action' are not yet implemented on Android or Firefox OS, though in the long term much of the code will be shared between all platforms, through the APZ controller. Plans: The implementation of Pointer Events should be complete enough to enable in desktop Nightly builds within the next few weeks. This will enable Pointer Events for mouse and pen input. (It will also enable Pointer Events for multi-touch input on Windows when e10s and APZ are enabled, though like APZ itself this is still experimental and will not yet be turned on by default.) If no serious problems are found, then we want to consider letting this feature ride the train to the Aurora/Dev.Edition channel (but not further). For the release and beta channels, we may want to wait until after touch input is ready to ship on Windows (depends on e10s + APZ), and we might also want to wait until it is ready to ship on Android and/or Firefox OS at the same time or soon after. When the time is closer, we will send an "Intent to Ship" email to this list for discussion. See also: This wiki page has some links to tracking bugs and other information: https://wiki.mozilla.org/Gecko/Touch ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: mozmake users, upgrade
On 12/10/2013 4:15 PM, Brian R. Bondy wrote: Is this the default right now? If someone follows the steps and gets the Mozilla Build package on that page[1], will their build fail or succeed? [1]: https://developer.mozilla.org/en-US/docs/Developer_Guide/Build_Instructions/Windows_Prerequisites That page points to the latest MozillaBuild release (1.8) which does not contain any version of mozmake. Someone who follows those instructions will not be affected by this bug, since their build will use pymake by default. The only people who affected by this bug are those who downloaded an early version of "mozmake.exe" and installed it manually. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Plug-in feature not available in the web platform. Alternatives?
On 11/8/2013 1:33 AM, fma spew wrote: 3- We haven't found any indication of Mozilla about alternatives for these kind of plug-ins, meaning plug-ins that need access to, in this case, Windows stuff. Google has provided alternatives though. One alternative is a Firefox extension. Firefox extensions can access both native platform APIs and web content. In particular, extensions can use js-ctypes to call C/C++ code. We've also mentioned the possibility of bundling a traditional plugin with a Firefox extension to change the default click-to-play behavior: "If a plugin is installed bundled within a Firefox extension, the extention can enable the plugin by default (for all sites or for particular sites) via preferences/permissions. Because the user chose to install the addon, I see no problem with allowing this sort of default activating." -- https://mail.mozilla.org/pipermail/firefox-dev/2013-September/000903.html ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cost of ICU data
On 10/17/2013 10:24 AM, Ehsan Akhgari wrote: We used to have codesighs measurements (and perhaps still do) but historically many people just ignored them. We stopped collecting codesighs measurements in November 2012 (bug 803736). As Ehsan says, it was widely ignored. It "regressed" constantly, and it never seemed reasonable to demand that people implement desired features and fixes without adding any code. For this reason, I'm a bit confused at the level of scrutiny of ICU's size when we've added many times that amount to our download size over the past couple of years without any pushback or even discussion. (On a related note, what happened to http://www.arewesmallyet.com/?) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: devolution of cleartype rendering in Fx chrome
On 10/16/2013 1:24 PM, Karl Tomlinson wrote: Many people use browsers for reading text, so I would like to claim that text rendering quality is usually more important than performance. I apologize for not looking through the referenced bugs. To repeat a point from my previous message: These bugs do not affect rendering of text on web pages. They are about rendering of specific items in the Firefox chrome. (That doesn't mean we should ignore the bugs; I'm just addressing the "people use browsers for reading" comment above.) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: devolution of cleartype rendering in Fx chrome
On 10/15/2013 1:36 PM, al...@yahoo.com wrote: Why are these ignored? I can't speak for anyone else, but I would guess it's because no one who has looked at them has figured out any useful information to add, or found the time to investigate further. As to whether we should pull someone off of other tasks to focus on these XP text-rendering bugs, that's tricky. They are user-visible regressions and a large portion of our users are on XP. On the other hand, they do not affect web content; XP is a (slowly) shrinking platform; and the difference between grayscale and subpixel AA is jarring to some users but subtle or invisible to others. In general, if I understand correctly, it's hard to use native subpixel AA in layers that use hardware accelerated compositing. So in some cases we might need to choose between speed and subpixel rendering. (I'm not at all an expert in this area, though.) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal: Email individual patch authors who improve performance
On 2013-08-12 6:14 PM, Matt Brubeck wrote: I've posted a patch that would change how the graph server sends email when a performance *improvement* is detected: https://bugzilla.mozilla.org/show_bug.cgi?id=904250 I landed this patch, and it will go live with the next graph server deployment. I also just landed some patches that should reduce the main causes of false alarms (bug 904322, bug 879903) to minimize any noise/spam from this change. On 8/16/2013 11:27 AM, Mike Hoye wrote: Can other addresses be CC'ed when this specifically (and in the future, other automatically-detectable improvements) are accomplished? I'd like to be able to automate badge-assignment stuff on Mozillians as much as possible, and this would be a big help. Yes -- you can either subscribe your address to the dev-tree-management mailing list to receive all of the emails, or you could add additional logic to the "emailWarning" function in this code: http://hg.mozilla.org/graphs/file/tip/server/analysis/analyze_talos.py If you want to do the latter, please file a bug in the "Release Engineering: Tools" component in Bugzilla. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal: Email individual patch authors who improve performance
On 8/13/2013 1:57 PM, Jet Villegas wrote: This is awesome! Is it possible to see a log of the recipients/patches? Yes - all of the emails for both regressions and improvements are also sent to the dev-tree-management list, which is archived at https://groups.google.com/forum/#!forum/mozilla.dev.tree-management ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Proposal: Email individual patch authors who improve performance
I've posted a patch that would change how the graph server sends email when a performance *improvement* is detected: https://bugzilla.mozilla.org/show_bug.cgi?id=904250 Emails about regressions would be unchanged. Emails about improvements would now be sent to individual patch authors using the same logic as regression emails: * If there are up to five authors in the regression range, email dev-tree-management and each of the patch authors. * If there are more than five authors, just email dev-tree-management. I've spoken to other developers in a few places, and most were in favor of this change. Those who don't want the extra emails can filter them out if they want to. Motivations for this change: - When you are expecting a patch to affect performance, the email is useful confirmation. Receiving it directly saves you the work of searching through the mailing list archives or manually inspecting graphs. - When you're not expecting a performance improvement, it may be important to know that one has happened so you can figure out why. (Sometimes it's a sign of a bug, for example if you accidentally disabled some code.) - Warm fuzzy feeling for developers who write perf wins! I think the accuracy of the analysis script is now good enough that this would not generate too many spurious emails. If you have any opinions or suggestions about this change, please share them here or in bug 904250! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: std::unique_ptr, std::move,
On 7/31/2013 4:06 AM, Brian Smith wrote: On Wed, Jul 31, 2013 at 12:34 PM, Mike Hommey wrote: I strongly oppose to any requirement that would make ESR+2 (ESR31) not build on the current Debian stable (gcc 4.7) and make ESR+1 (ESR24) not build on the old Debian stable (gcc 4.4). We're not going to change the requirements for the latter. And b2g still requires gcc 4.4 (with c++11) support anyways. Until they switch to the same toolchain as android, which is 4.7. Why are you so opposed? I feel like I can give a lot of good reasons why such constraints are a net loss for us, but I am not sure what is driving the imposition of such constraints on us. I agree that this constraint would have a cost for us. Since you ask, I'll try to explain some of the benefit; then we can try to decide which outweighs the other. Firefox users on Linux typically depend on their distribution to provide security updates. Needing to backport new compiler versions to old OS releases would raise the cost for those distributors to publish Firefox updates, possibly to the point where it is no longer feasible. If so, Linux users might lose the ability to easily install Firefox and keep it up to date. (They would still have the option of downloading tarballs from ftp.mozilla.org, but this is not really something that I expect any non-expert users will do.) If we want Firefox for Linux to remain viable for Linux users, then we probably need to be willing to do *some* work to make it so -- either by supporting the compiler versions available in their distributions or by providing our own package repositories for popular distributions (like Google Chrome does). Otherwise we might need to tell our Linux users to switch to Chrome if they want a usable way to install a secure browser. Now, I don't think we need to do *quite* as much work as glandium proposed above. For example, I think it would be enough to support just the current Debian stable rather than the current and previous stable versions. Users who want an up-to-date Firefox can update their distribution. Debian doesn't keep Iceweasel up to date in oldstable anyway. (Also: at the moment B2G is holding us back more than Debian Stable. If we can't use the latest compiler on our *own* Linux distribution, why do we expect other distributors to do better?) My position is that we should be doing everything we can to improve developer productivity But this is clearly not an absolute, otherwise we'd do things like drop Windows XP and OS X 10.6 support today. We are clearly willing to pay some productivity cost in order to support a wider range of platforms, and so we need to talk about trade-offs rather than unwavering principles. As for whether we should care about Linux users: Just counting users is not enough. For example, a disproportionate number of our contributors come from the Linux world. If Firefox had not been a good browser on Linux, I would probably not be a Firefox user or developer today. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Shutting off leak tests?
On 7/17/2013 4:26 AM, Ted Mielczarek wrote: The only valuable thing we're losing from shutting this off is tracemalloc coverage, which we don't have elsewhere. I don't have any evidence to show that anyone has actually looked at the tracemalloc data or done anything useful with it in recent history, though. Leaks discovered by tracemalloc don't make the test fail, so we're not measuring much there. Trace Malloc measures three things: leaks, max heap size, and number of allocations. All of these are reported to the graph server and use the same monitoring as Talos benchmarks. Like Talos data, this data does not have a consistent process or owner responsible for watching it or improving it, but there are some people who watch for alerts from the monitoring script and try to investigate regressions. Trace Malloc Leaks is a fairly stable measurement; our monitoring has not found regressions in it very often, but it does occasionally (about once a year?) help alert us to an actionable bug that might have been harder to fix otherwise. The latest example is: https://bugzilla.mozilla.org/show_bug.cgi?id=872947 Trace Malloc MaxHeap is somewhat useful, but largely overlaps with the measurements produced by AWSY and Tp5, both of which are probably more useful and representative. Trace Malloc Allocs is not very useful from what I understand; a change in this benchmark does not necessarily correlate with any user-visible change. So the main thing we'd lose is graph server monitoring of Trace Malloc Leaks. This is occasionally useful, but in a limited way because the monitoring process is unowned, and because the current value of the benchmark is high enough that small changes are ignored by the monitoring system. It has some chance of sometimes making large regressions easier to detect. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Embracing git usage for Firefox/Gecko development?
On 5/31/2013 12:32 PM, Boris Zbarsky wrote: On 5/31/13 3:20 PM, Matt Brubeck wrote: blame mobile/android/chrome/content/browser.xul: git 1.015s hg 0.830s Was this a git blame -C (which would be more similar to hg blame), or just a git blame? Good catch. (Sorry, I missed your messages on IRC warning me about this.) The above numbers were without -C. "git blame -C" takes about 3.7 seconds on this file. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Sandboxed, off-screen pages for thumbnail capture
On 6/17/2013 9:48 PM, Drew Willcoxon wrote: The desktop Firefox team is building a new Toolkit module that captures thumbnails of off-screen web pages. Critically, we want to avoid capturing any data in these thumbnails that could identify the user. More generally, we're looking for a way to visit pages in a sandboxed manner that does not interact with the user's normal browsing session. Does anyone know of such a way or know how we might change Gecko to support something like that? What about launching/forking a separate process to capture thumbnails for these pages? I don't mean an Electrolysis-style child process that is tightly coupled to the browser, but rather a separate program that does not use the Firefox profile at all. The browser would pass this program a URL and it would just render a page and save the thumbnail. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Windows XP virtual memory peak appears to be causing talos timeout errors for dromaeo_css
On 6/3/2013 7:28 AM, jmaher wrote: We have a top orange factor failure which is a talos timeout that only happens on windows XP and predominately on the dromaeo_css test. What happens is we appear to complete the test just fine, but the poller we have on the process used to manage firefox never indicates we have finished. After doing some screenshots and looking at the process list, I haven't found much except that on the failing cases the _Total value for "Virtual Bytes Peak" is >2GB, and for all the passing instances it is ~1.25GB. Are there other things I should look for, or things I could change to fix this problem? This *might* be related to bug 859955 which a few people have been actively working on recently: https://bugzilla.mozilla.org/show_bug.cgi?id=859955 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Embracing git usage for Firefox/Gecko development?
On 5/30/2013 5:56 PM, Johnny Stenback wrote: Some of the known issues with embracing git are: * Performance of git on windows is sub-optimal (we're already working on it). This has become a bit of an urban legend; I often see it repeated but seldom with actual measurements. I don't think it's a valid reason to avoid git unless there are specific cases where git's performance on Windows is insufficient compared to hg's performance on Windows. In some brief tests using hg.mozilla.org/mozilla-central versus github.com/mozilla/mozilla-central on a modern Core i7 laptop with SSD and 8GB RAM, after throwing away the first result (so I'm measuring "warm cache" times; "cold" times would be useful too but would take more work for me to measure correctly): log the last 10,000 changes: git 0.745s hg 2.570s blame mobile/android/chrome/content/browser.xul: git 1.015s hg 0.830s diff with no changes: git 2.136s hg 2.001s status: git 3.011s hg 1.680s commit one-line change to configure.in: git 2.420s hg 3.911s clone from remote: git 26m43s hg 19m01s pull from remote to an up-to-date clone: git 1.585s hg 0.875s update working dir from tip to FIREFOX_AURORA_23_BASE: git 16.008s hg 25.704s There *are* some cases where git is worse than hg on Windows, but hg is as bad or worse for many common operations like log, diff, and commit. Overall I find both painful on Windows, but neither noticeably better than the other. (And of course some of these tests are highly unfair because the git repo has a more complete history than the hg one, or because they test network or server performance that is unpredictable and may vary between github and hg.m.o.) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal for an inbound2 branch
On 5/2/2013 6:21 AM, Ehsan Akhgari wrote: On 2013-05-02 5:46 AM, Neil wrote: Why do we need a separate repo? Can we not simply close the broken head and start again at the last green changeset? Multiheaded repos are evil. They're very hard to deal with, and I don't think that buildbot can deal with them properly. Buildbot can deal with a multi-headed Try, so it can probably be convinced to deal with a multi-headed inbound, even if it needs to be a special case like Try. Individual developers might have more problems (they'll want to pull from inbound, unlike Try) but I think as long as the inactive heads are closed it won't freak out Mercurial too much... The suggested workflow with inbound2 would lead to almost-identical multi-headed repos in developers' local clones anyway. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: multiline pref value strings in user.js
On 4/27/2013 3:26 PM, al...@yahoo.com wrote: ... appear to be possible without the \ escape. In fact the \ can not be present as it does not escape the newline but becomes a part of the string. So it does not seem to follow js rules, so what is this format? The format doesn't have a name that I know of; it's "that weird format that prefread.cpp parses" and it's not really documented except: http://mxr.mozilla.org/mozilla-central/source/modules/libpref/src/prefread.cpp#151 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal for an inbound2 branch
On 4/26/2013 4:14 PM, Justin Lebar wrote: If I have a patch ready to land when inbound closes, what would be the sequence of steps that I need to do to land it on inbound2? Would I need to have an up-to-date inbound2 clone and transplant the patch across? I think mbrubeck or someone knows how to maintain multiple hg branches in one repo, but I've never figured that out... Yes, having been a git user for years before I started with Mercurial, I simply treat Mercurial as a slightly crippled version of git. :) hg clone https://hg.mozilla.org/mozilla-central/ cd mozilla-central # hack on some stuff # do some builds and tests hg new my-patch # time to push to inbound: hg qpop hg pull https://hg.mozilla.org/integration/mozilla-inbound/ hg up -c hg qpush && hg qfin my-patch hg push -r tip https://hg.mozilla.org/integration/mozilla-inbound/ # Now, let's backport something to Aurora! hg pull https://hg.mozilla.org/releases/mozilla-aurora/ hg export -r a3c55bdbe37d | hg qimport -P -n patch-to-uplift hg push -r tip https://hg.mozilla.org/releases/mozilla-aurora/ # After a good night's sleep, back to work! # hg pull -u won't work across branches, so: hg pull https://hg.mozilla.org/mozilla-central/ hg up -c # do a build # start hacking again! This sort of workflow is of course much more natural in git, which makes it easy to track the state of the remote repo(s). The bookmark workflow that gps added to MDN basically emulates part of the functionality of git remote tracking branches. I'm actually astounded that Mercurial doesn't have better support for this built in; I see Mozilla developers doing crazy time-consuming things all the time because of Mercurial's poor support for working with remote repositories. :( ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
"Experimental Technology" in Gecko (Re: Storage in Gecko)
On 4/26/2013 11:43 AM, Gregory Szorc wrote: Have you explored using IndexedDB? Not seriously. The "this is an experimental technology" warning on MDN is off-putting. The largest audience for MDN is web developers, so we put that warning on anything that's not ready for widespread use on the public web, including most things that are prefixed in current browsers. Here are some other things with the same "experimental technology" warning on their MDN pages: * JavaScript "for...of" loops * CSS transform, transition, animation * WebSocket * Set, Map, WeakMap Obviously we have no qualms against using these ourselves. When an experimental technology is one that *we* are promoting as part of the development platform *we* are building, then of course we should using it in our own code. In fact we should be early adopters, because if there are issues that prevent us from using our own APIs, then they will often affect other developers on our platform, so we need to know about those and fix them. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Improving Mac OS X 10.6 test wait times by reducing 10.7 load
On 4/26/2013 9:10 AM, Armen Zambrano G. wrote: Just disabling debug and talos jobs for 10.7 should reduce more than 50% of the load on 10.7. That might be sufficient for now. I'd be happy for us to disable all Talos jobs on 10.7, on all trees. I've been keeping track of Talos stuff recently and I have not seen any genuine regressions that are 10.7-specific, so I don't think it's providing us much benefit to run these benchmarks on three Mac platforms simultaneously. In terms of tracking regressions, it would be better to have more complete data 10.6 alone than to have incomplete data (due to coalescing) on 10.6 and 10.7. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Preparing for the next windows PGO build memory exhaustion
On 4/18/2013 12:10 PM, Matt Brubeck wrote: Since we run PGO builds only a few times a day, the ranges can be large. For those that include m-c merges, you could narrow them down using the m-c data. WebIDL seems to be a common theme. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=863492 to investigate whether Paris bindings are a particular contributor to linker memory usage, and possible solutions. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Preparing for the next windows PGO build memory exhaustion
On 4/17/2013 3:07 PM, Matt Brubeck wrote: analyze_talos.py does identify several real regressions in that dataset -- but it suppresses emails for them because each one is an increase of less than 2% (see bug 822249). Here are regressions identified by the latest version of analyze.py: In case anyone wants to investigate these, I've added regression ranges below. These are automatically generated; I haven't double-checked them manually. Since we run PGO builds only a few times a day, the ranges can be large. For those that include m-c merges, you could narrow them down using the m-c data. WebIDL seems to be a common theme. changesetmem (KB) t-test % change c1ee454506f6 329686 139.519 1.05% http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=88543d623c3f&tochange=c1ee454506f6 (Includes several Paris bindings changes, among others) 0acac77dd920 333029 11.809 0.99% http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=16ddbb6852ec&tochange=0acac77dd920 (More Paris binding changes, and others) e6ca584f4fe7 335801 9.753 0.86% http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=a69f329fc7ee&tochange=e6ca584f4fe7 (includes the Win8 Metro merge) 80d52655c8b8 339830 74.742 0.45% http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=4637a1449900&tochange=80d52655c8b8 (includes some WebIDL-related changes) d27445d1eac5 345040 26.214 0.99% http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=92824d900e25&tochange=d27445d1eac5 eaff15332579 346897 70.525 0.52% http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e38c5c346840&tochange=eaff15332579 (Olli Pettay — Bug 822399 - Make Event to use Paris bindings) Perhaps we should modify bug 822249 to ignore the 2% threshold for specific tests where we *do* care about small changes. Or for any change with a very high t-test score. I filed this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=863061 A fix has been checked in, so we should start getting alerts for future linker memory regressions of any size. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Preparing for the next windows PGO build memory exhaustion
On 4/13/2013 1:28 AM, Mike Hommey wrote: The first thing to notice in here is the 13 spikes down. The last one is bug 860371. I wasn't aware of any of the 12 others. It might be worth looking into them to understand why they happen. Interestingly, my dev-tree-management archive doesn't show any notification for these (except for the last one), nor for any of the progressive "regressions". analyze_talos.py intentionally ignores transient changes. Until recently it required 5 new test runs to show a statistically significant difference from the preceding 30 runs. (Bug 858877 changed this to 12 new runs and 12 preceding runs, but the concept is still the same.) So it's expected that the one-time spikes were ignored. analyze_talos.py does identify several real regressions in that dataset -- but it suppresses emails for them because each one is an increase of less than 2% (see bug 822249). Here are regressions identified by the latest version of analyze.py: changesetmem (KB) t-test % change c1ee454506f6 329686 139.519 1.05% 0acac77dd920 333029 11.809 0.99% e6ca584f4fe7 335801 9.753 0.86% 80d52655c8b8 339830 74.742 0.45% d27445d1eac5 345040 26.214 0.99% eaff15332579 346897 70.525 0.52% 0ff1755d6359 279976 263.117 -21.58% 1c690be31939 358659 11.241 28.06% Perhaps we should modify bug 822249 to ignore the 2% threshold for specific tests where we *do* care about small changes. Or for any change with a very high t-test score. I filed this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=863061 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: A new way to run mach
On 4/17/2013 10:50 AM, Gavin Sharp wrote: I think Rob was talking about the case where you would call e.g.: "mach build browser/base" mach could know that on Mac, that also requires the equivalent of "mach build browser/app" for those changes to actually be repackaged into the bundle in objdir/dist/, because the build system doesn't. The plan for cases like this is to integrate jdm's "smartmake" code into the build system and allow "mach build" to use it: https://bugzilla.mozilla.org/show_bug.cgi?id=677452 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: A new way to run mach
On 4/15/2013 11:04 AM, Rob Campbell wrote: On Mac, does mach do the right thing when you rebuild browser, does it also rebuild browser/app so your application bundle gets updated? "mach build browser" is the same as "make -C $objdir/browser" (literally, it just executes that "make" command to do all the work), so just like "make" it should rebuild all of the sub-directories too as long as the dependencies are correct. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Landing on Trunk - Target Milestone vs. Status Flag Usage vs. Tracking for Future Releases
On 4/10/2013 5:14 PM, Gregory Szorc wrote: I don't really have much to say on the specifics of this post other than a simple question: why don't we have a checkin hook or bot automatically update Bugzilla flags when changesets are pushed? This would save developer time and would reduce the error rate of bugs not updated properly (especially when you consider that policies change over time). http://www.graememcc.co.uk/m-cmerge/ is a tool that will automatically resolve bugs and set Target Milestone correctly for patches pushed to m-c. It's used by most of the people who regularly merge from inbound and other branches to m-c. It still needs to be invoked explicitly by the person who lands/merges the patches, so it's not a fool-proof automatic solution. Just pointing it out for anyone following who doesn't know about this part of the process. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
CSS outline-color: invert
Support for "outline-color: invert" was removed in Firefox 3, and a bug to restore support was RESOLVED WONTFIX several years ago because it was deemed infeasible while using hardware acceleration [1]. Since then, some developers have asked for reconsideration on the bug; since some of their questions in the bug remain unanswered, one developer asked me to bring it up here. The specific question is whether the many changes to our graphics acceleration since 2009 have made it any more feasible to implement "invert" today. Do IE or Opera use any tricks to do this that could be useful for us too? In addition to the obvious use case of making outlines visible against multiple background colors, apparently this can be used for hacks [2] to invert entire regions, similar to David Baron's SVG filter demo [3] but possibly more flexible. [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=359497#c24 [2]: http://lea.verou.me/2011/04/invert-a-whole-webpage-with-css-only/ [3]: http://dbaron.org/log/20110430-invert-colors ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
A new way to run mach
I recently landed a new feature for the "mach" build tool [1]. You can now run mach from anywhere in the mozilla source tree. To get started, add mach to your $PATH. You can do this by changing the PATH environment variable to include the mozilla source directory, or by copying the "mach" script from your source directory to a location like /usr/local/bin. Then you can run mach commands from anywhere in your source directory, and you can use paths within your current directory. For example, if you are working on some devtools code you might run commands like: cd browser/devtools # Rebuild the code in browser/devtools/webconsole: mach build webconsole # Run browser-chrome tests from browser/devtools/webconsole/test: mach mochitest-browser webconsole/test # Most commands work the same no matter where you run them: mach clobber mach build # Do a full rebuild mach package mach install You can also run "mach" within an objdir. If you have multiple objdirs with different mozconfigs, mach automatically defaults to the mozconfig that built the current objdir. This means you can switch between configurations as easily as: cd obj-debug mach build mach xpcshell-test cd ../obj-optimized mach build mach xpcshell-test (Note: the automatically-detected mozconfig is used as a default, but you can still override it by explicitly setting the MOZCONFIG environment variable.) The "mach" script is now just a wrapper; it loads the actual mach code and configuration from whichever source directory you run it in. So you can add mach to your path once and it should work with any current or future mozilla-central directory. (For older trees, like the current aurora or beta repos, you still need to run mach the old way, using "./mach" in the top source directory.) For development details, please see bugs 840588 and 840690 (but note that the feature changed a bit since those bugs were first filed). Huge thanks to gps and all the other people who helped in the design and implementation of this feature! [1] https://developer.mozilla.org/en-US/docs/Developer_Guide/mach [2] https://bugzilla.mozilla.org/show_bug.cgi?id=840588 [3] https://bugzilla.mozilla.org/show_bug.cgi?id=840690 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
setTimeout without a DOM window using Timer.jsm
I noticed a number of places in Mozilla code where setTimeout-like functionality is needed, but DOM window.setTimeout is not available because the code runs in a non-DOM context like a JSM. In a few places we had created pure-JS implementations of window.setTimeout to solve this problem. With Gavin's encouragement, I extracted one of these into a standalone JSM file, to make it easier to share. If you need to call setTimeout without a DOM window, you can now use Timer.jsm: https://developer.mozilla.org/en-US/docs/Mozilla/JavaScript_code_modules/Timer.jsm This offers two main benefits over just using nsITimer directly: it makes it easier to re-use code written for use in a DOM window, and it addresses this common nsITimer garbage collection problem: http://www.joshmatthews.net/blog/2011/03/nsitimer-anti-pattern/ For more details, see bug 840360. Thank you to Chris Jones who wrote the original code, and to several other people who gave feedback on it. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Upcoming separation between resource://app and resource://gre
On 2/7/2013 6:12 AM, Mike Hommey wrote: - But really, what does it change for developers? Almost nothing they shouldn't be doing already. The main difference is that resource://app/ and resource://gre/ urls are not going to point to the same location anymore, which means I won't have to file bugs about $randomFile including resource://gre/modules/something.jsm instead of resource://app/modules/something.jsm. This seems like a major add-on compatibility issue. Has anyone looked into how many add-ons will now have incorrect resource: URIs? How can we scan for these, and how can we mitigate the breakage? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: UA string: "Touch" or "Tablet" again
Here is my personal suggestion for how we should handle this in our "Metro" browser, and the reasoning behind my proposal. This is meant to be a minimal step to bring Firefox for Metro in line with other platforms, without making changes to any other products. It might need to be tweaked if we make any broader, cross-platform UA changes. This was originally posted at: https://bugzilla.mozilla.org/show_bug.cgi?id=809396#c5 ASSUMPTIONS: A. The UA header is used mainly by sites that serve very different content to different devices. Sites that use the same basic UI for both mouse and touch can serve a single page that works with both types of input and uses feature detection to determine browser capabilities as needed. B. For any site that serves different content to "desktop" and "mobile" users, some portion of users will disagree with the site's default (no matter which is the default) and will want to switch to the other version. C. Users of touch-screen devices will sometimes interact with the device primarily through touch, and sometimes interact primarily with a mouse / trackpad / other "precise" pointer device. (Some users will stick to one interaction type all the time, while others may switch back and forth even on the same device.) D. *Most* people will prefer the touch-friendly "Metro" Firefox UI while they are interacting primarily through touch, and *most* people will prefer the mouse-friendly "desktop" Firefox UI while they are interacting primarily with precise pointer devices. E. Many web developers will test on only one or two device types. More variations in the User-Agent header would mean more developers who mishandle some of those variations without realizing it. PROPOSAL: * We should add "Tablet" to the User-Agent header when the the Metro Firefox UI is used *and* the hardware supports touch input. * For non-touch hardware, we should make no changes to the User-Agent header. * For the classic (desktop) Firefox UI, we should make no changes to the User-Agent header. PROS: * Users who browse in the mouse-friendly Windows desktop environment will see no changes in content. In particular, users of touch-compatible desktops or notebooks who nonetheless prefer the traditional "desktop" environment will generally see familiar desktop-style web content. * Users who browse in the touch-friendly Windows "Metro" environment are likely to get touch-optimized content by default. * Sites are unlikely to serve touch-only content to users without touch hardware. * Users have an easy and (somewhat) intuitive way to choose between the "tablet" and "desktop" versions of sites, for example by using Metro Firefox's "View in desktop" command. * Sites that follow our existing guidelines to send tablet-optimized content to Firefox for Android tablets will not need any changes, and will immediately begin serving tablet-optimized content to Firefox for Metro. CONS: * "Tablet" is not widely used by other browser vendors. "Touch" would be consistent with Internet Explorer. * "Tablet" is kind of misleading since it refers to a specific form factor and is not accurate for all devices where people use our touch UI. "Touch" might look more "right", and be more self-documenting. For example, some authors might wrongly assume "Tablet" implies a certain screen size. These and many related issues are discussed in much more detail at: https://bugzilla.mozilla.org/show_bug.cgi?id=773355 QUESTIONS: Q. Why "Tablet" and not "Touch"? Mainly for consistency with our current UA header, especially on Android. Using both "Tablet" and "Touch" would complicate our UA, adding more variations and more chances for authors to make errors. Switching from "Tablet" to "Touch" would undo some of our evangelism work over the past year, and would involve a transition where both variations exist, again complicating web development and testing. However, I think this is a reasonable question to discuss in bug 773355, and I believe the rest of this proposal would still make sense if we replaced "Tablet" with "Touch" everywhere. Q. What about users who want to use desktop Firefox *and* interact with web pages through touch? Ideally, most web developers would use feature detection instead of UA sniffing, and serve a single page with good support for both touch and mouse interaction, which will work in all browsers. But for sites that do use UA sniffing, the best we can do is help developers choose defaults that work best for the majority of users. Users who dislike the default can easily change it by switching between Metro and desktop Firefox, or by using an add-on or about:config to change the header. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The current state of Talos benchmarks
On 08/29/2012 04:03 PM, Ehsan Akhgari wrote: I don't believe that the current situation is acceptable, especially with the recent focus on performance (through the Snappy project), and I would like to ask people if they have any ideas on what we can do to fix this. The fix might be turning off some Talos tests if they're really not useful, asking someone or a group of people to go over these test results, get better tools with them, etc. But _something_ needs to happen here. Thanks for starting this discussion. I have some suggestions: * Less is more. We can pay more attention to tests if every alert is for something we care about. We can *track* stuff like Trace Malloc Allocs if there are people who find the data useful in their work, but we should not *alert* on it unless it is a key user-facing metric. * I don't like our reactive approach that focuses on trying to identify regressions, and then decide whether to fix them in place, back them out, or ignore them. Instead we should proactively set goals for what our performance should be, and focus on the best way to get it there (or keep it there). The goals should be based the desired user experience, and we should focus only on metrics that reflect those user experience goals. * Engineering teams should have to answer for these metrics; for example they should be included in quarterly goals. At Amazon, item #1 in the quarterly goals for each team was always to meet our metrics commitments. Slipping a key metric past a certain threshold should stop other work for the team until it's rectified. * We need staff whose job includes deciding which regressions are meaningful, identifying the cause, following up to make sure it's backed out or fixed, and refining the process and tools used to make all this possible. Too much slips through the cracks when we leave this to volunteers (including "employeeteers" like Ehsan or me). ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The current state of Talos benchmarks
On 08/29/2012 04:32 PM, Nicholas Nethercote wrote: In my experience, a lot of those emails say "there was a regression caused by one of the following 100 patches", and I will have written 1 of those patches. I usually ignore those ones (though it depends on the nature of the patch). But if I get an email saying something like "there was a regression caused by one of the following 3 commits", I'll look into it. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=752002 to stop sending mail to every single author when the regression range includes a large number of patches. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
