RE: All the processes
> -Original Message- > From: dev-platform [mailto:dev-platform- > bounces+jmathies=mozilla@lists.mozilla.org] On Behalf Of Nicholas > Nethercote > Sent: Friday, March 03, 2017 6:15 PM > To: dev-platform <dev-platform@lists.mozilla.org> > Subject: All the processes > > Hi, > > I want to understand all the different processes that we can and will have > in Firefox. Here's a list I constructed off the top of my head. > > - main process > > - content process(es): 1 on release for most users; 2 on Nightly > > - plugin process: just for Flash now? > > - gfx compositor process (bug 1264543, in Fx53) > > - file:// URL access process (bug 1147911, in Fx53) release target for this feature is currently fx54. > > IIRC there was a proposal for a thumbnail generation process a while back > but judging by bug 1187441 that was scrapped. This currently happen in one of the content processes. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Too many oranges!
On Monday, December 21, 2015 at 1:16:13 PM UTC-6, Kartikaya Gupta wrote: > So, I propose that we create an orangefactor threshold above which the > tree should just be closed until people start fixing intermittent > oranges. Thoughts? > > kats How about regularly scheduled test fix days where everyone drops what they are doing and spends a day fixing tests? mc could be closed to everything except critical work and test fixes. Managers would be able to opt individuals out of this as needed but generally everyone would be expected to take part. Jim ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
FYI: e10s will be enabled in beta 44/45
Hey all, FYI e10s will be enabled in beta/44 in a limited way for a short period time through an experiment. [1] The purpose of this experiment is to collect e10s related performance measurements specific to beta. The current plan is to then enabled e10s in beta/45 for a respectable chunk of our beta population. This population will *exclude* users who have recently loaded accessibility and users who have a large number of addons installed. If you know of serious e10s related bugs in your components that you feel should be fixed for the beta/45 rollout please get those bugs tracked for 45 and owned. If you have any issues or questions you can tag the bug with tracking-e10s:? and the e10s team will come through to help triage. Thanks! [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1229104 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1218484 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: FYI: e10s will be enabled in beta 44/45
On Friday, December 4, 2015 at 9:44:36 AM UTC-6, Ehsan Akhgari wrote: > On 2015-12-04 9:02 AM, jmath...@mozilla.com wrote: > > Hey all, > > > > FYI e10s will be enabled in beta/44 in a limited way for a short period > > time through an experiment. [1] The purpose of this experiment is to > > collect e10s related performance measurements specific to beta. > > > > The current plan is to then enabled e10s in beta/45 for a respectable chunk > > of our beta population. This population will *exclude* users who have > > recently loaded accessibility and users who have a large number of addons > > installed. > > > > If you know of serious e10s related bugs in your components that you feel > > should be fixed for the beta/45 rollout please get those bugs tracked for > > 45 and owned. If you have any issues or questions you can tag the bug with > > tracking-e10s:? and the e10s team will come through to help triage. > > Does this mean that not all tracking-e10s+ bugs will need to be fixed > before we ship e10s? What's the indicator that a bug "blocks" shipping > e10s? That's a flag for bugs we want to keep track of but it does not include bugs that block rollout. We currently have two blocking lists, our ongoing milestone-8[1] and P1 performance bugs[2]. [1] http://is.gd/gL9Qfj [2] http://is.gd/N4Kska Jim ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: FYI: e10s will be enabled in beta 44/45
On Friday, December 4, 2015 at 11:08:08 AM UTC-6, Armen Zambrano G. wrote: > LastPass bring the browser to a crawl making it almost impossible to > use. If we have users using LastPass on the beta population using e10s > we're going to have a lot of people upset. Not an issue since initial rollout to beta and release will be to users who do not have addons installed. Jim ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Shutdown hangs are very common
On Monday, July 6, 2015 at 3:52:39 PM UTC-5, Kyle Huey wrote: On Mon, Jul 6, 2015 at 1:37 PM, Ryan VanderMeulen rya...@gmail.com wrote: On 7/6/2015 4:34 PM, Vladan D wrote: Background: Firefox shutdown hangs are turned into shutdown crashes by a watchdog thread [1] that forces a crash if shutdown hasn't completed within 1 minute. Thanks to the watchdog and the Windows profile unlocker [2], shutdown hangs aren't as frustrating as they used to be. However, shutdown hangs might still be causing data loss and they are indicative of potentially-serious bugs in the code. According to this graph of Firefox crash rate history, shutdown hangs (crashes) make up about one third of all browser crashes [3]: https://crash-analysis.mozilla.com/rkaiser/crash-report-tools/longtermgraph/?fxrel I've been told shutdown hangs often don't get enough attention. Should fixing shutdown hangs be higher priority? And if so, should we allow features with shutdown hangs to be released? Notes: 1. Force Firefox crash if shutdown hangs https://bugzilla.mozilla.org/show_bug.cgi?id=1038342 2. win32 implementation of nsIProfileUnlocker https://bugzilla.mozilla.org/show_bug.cgi?id=286355 3. The graph above shows that the overall crash rate jumped up by roughly a third when the watchdog code shipped in Firefox 36. Hover over the 36 box on the blue line Windows mochitest-bc shutdown hangs have been on of the top oranges in our automation for months now. See bug 1121145. Would be great if we could get more eyes on the problem. -Ryan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform The last five logs in that bug are all hanging in QuotaClient code. I'll take a look. - Kyle Bug 1160459 was filed on the QuotaClient problem, it's a parent of the test failure bug. There's some discussion in there about the problem which you were involved in fyi. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Treeherder UI performance much worse in Nightly vs Chrome
Maybe this bug 1157409 bleeding through to non-apzc? Perf on tree herder sucks for me too, and I have apzc off today. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Excessive inbound bustage
On Tuesday, April 21, 2015 at 3:03:37 AM UTC-5, Gabriele Svelto wrote: On 21/04/2015 08:25, Gabor Krizsanits wrote: Maybe because I usually work on core, and such confidence is hard to reach there, but I'd like to think at least a try run that check if the patch builds on all platform and a full test run on at least one platform is not too much sacrifice of ones time. Personally I think that my time is cheaper than everyone's time. It is slow. It is annoying, but holding up ALL the other patches/developers is expensive hence a risky option. So I suggest everyone to be very conservative about that confident feeling. I agree; since I work mostly on patches that are relevant for FxOS/B2G I always run a try build across all architectures before to ensure it doesn't break anything else. Somehow I was under the impression that everybody did that. Gabriele I think this should be standard procedure for anyone working on platform. A push to try for a base set of builds (mac, linux, win, b2g ics) plus a good set of tests (usually for me it's mochitests) covers things. Once those mostly complete I can mark the bug with check-needed and walk away, tree drivers will handle the landing when inbound is open and green. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Excessive inbound bustage
On Tuesday, April 21, 2015 at 2:11:43 PM UTC-5, Andrew Halberstadt wrote: On 21/04/15 03:02 PM, Aaron Klotz wrote: On 4/21/2015 12:50 PM, Andrew Halberstadt wrote: This could be effective, but if not implemented with care it could also be very de-motivating, especially for a well-intentioned contributor. Is this really an issue though, given the time and effort required to earn sufficient commit access to push to inbound? It's the patch author that is on the hook for bustage, not the pusher. Any contributor can land a patch on inbound by setting 'checkin-needed' on the bug. But contributors aside, it could be de-motivating for employees too. If I break inbound, I already feel really bad about it.. no need to rub it in my face :). I think we're being bit too sensitive here, I'm sure we can all handle a little public shaming on stuff like this. :) If you find yourself on the top of a list like list, and you feel a bit bad about it, good. Learn from it, push to try more often. That's the whole point. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Talos on e10s is broken. Do we care?
Do we realistically care about keeping this working? With perfherder graphs, we now have a way of visualizing/tracking relative performance (http://wrla.ch/blog/2015/02/measuring-e10s-vs-non-e10s-performance-with-perfherder/), though I'm not sure if that's really telling us anything we don't already know. We're rolling e10s out this year so e10s and non-e10s talos numbers are important. Long term e10s numbers are all we will care about since non-e10s will be unsupported. If we *do* decide we care about these results, I think we should (1) enable e10s runs on integration branches and (2) commit to backing out commits that break talos on e10s (i.e. unhide them) We do and I agree, they should be visible and running as often as regular talos runs trigger. e10s perf regressions on Nightly should be treated the same way other talos regressions would. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Turning off Overscroll on Windows touchscreen scrolling
On Sunday, December 28, 2014 7:20:25 PM UTC-6, Aaron Travis wrote: I've noticed that when you're scrolling a text field on a Windows touch screen and you reach the end of the scroll, the entire program pulls in the direction of the scroll and then snaps back. Not just the text field, but all of Firefox slides and then rubber bands back. I'd like to turn this off in the code. Does anyone know where I could find this in the source code? Right here - http://mxr.mozilla.org/mozilla-central/source/widget/windows/nsWinGesture.cpp#257 http://mxr.mozilla.org/mozilla-central/source/widget/windows/nsWinGesture.cpp#493 No prefs associated with this currently, feel free to add one if you like and flag me for review. Jim ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: e10s is now enabled by default for Nightly!
Three? I've only seen two... Really three or more depending on the number of plugins you have running, usually just flash. Plugin processes are now owned by the chrome process so, chrome, a single process for content for now, and a set of plugin processes. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: e10s is now enabled by default for Nightly!
On Friday, November 7, 2014 4:39:28 PM UTC-6, Gijs Kruitbosch wrote: Are we currently planning to let this default ride into aurora in 2 weeks' time? ~ Gijs Lots of bugs to fix before we roll out. We're currently finishing up milestone 4 bugs. m5/m6 block rollout to aurora, m7/m8 block rollout to beta. We triage new bugs twice a week so we'll be adding / adjusting these lists over time since m7/m8 are still largely unfilled. If you have free time, or just run into something that bugs you that we don't have as a priority, please dive in and try to fix it. Everyone should start familiarizing themselves with the idiosyncrasies of debugging three processes at once, it'll be the norm this spring. (..and just you wait until we turn on process-per-domain!) M4 bugs: http://is.gd/XKZkQ5 M5 bugs: http://is.gd/7MuzQK M6 bugs: http://is.gd/yOVr9r (aurora uplift when completed) M7 bugs: http://is.gd/ckXKll M8 bugs: http://is.gd/jUNCg5 Jim ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: How many tests are disabled? (answer inside)
Is there any chance you could generate a report on tests disabled in e10s mode? This would be very useful for the e10s team as we currently have a lot of tests disabled which need to get fixed. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
browser.tabs.remote - R.I.P.
Bug 1072417 landed yesterday removing support for browser.tabs.remote on mozilla-central, this will percolate its way out to release over the next few months. Everything gated on browser.tabs.remote is now on by default or has been dealt with using other means. browser.tabs.remote was the original e10s pref, but was superseded by browser.tabs.remote.autostart a year or so ago. The original pref ended up controlling a small, odd chunk of internal e10s functionality, and was also being used to control a few code paths for differentiation between desktop and b2g. Hence its removal. Please use the e10s checkbox in Options to get into e10s mode for testing. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
We then tried to get a sense of how much of a win the PGO optimizations are. Thanks to a series of measurements by dmandelin, we know that disabling PGO/LTCG will result in a regression of about 10-20% on benchmarks which examine DOM and layout performance such as Dromaeo and guimark2 (and 40% in one case), but no significant regressions in the startup time, and gmail interactions. Thanks to a series of telemetry measurements performed by Vladan on a Nightly build we did last week which had PGO/LTCG disabled, there are no telemetry probes which show a significant regression on builds without PGO/LTCG. Vladan is going to try to get this data out of a Tp5 run tomorrow as well, but we don't have any evidence to believe that the results of that experiments will be any different. Are the test run stats we're using here published somewhere? We should be tracking all this testing some place (a wiki page maybe?) so people can do their own investigation. I've always wondered if the tests we run during the pgo phase are sufficient to get good coverage over the entire app. Is it possible that we don't see gains in other areas because our pgo tests don't hit those areas? (I think there was an effort under way to expose these tests so they could be modified in try runs for better experimentation.) Generally I would make disabling pgo the last option after exhausting all other options. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
On Thursday, January 31, 2013 8:14:01 AM UTC-6, Gregory Szorc wrote: My reading of Ehsan's summary is that there is no significant *user* benefit (read: perf win) of PGO. If there is no *user* benefit, then the only data that remains to justify PGO are the benchmark results. Therefore, I believe we should disable PGO unless there is a convincing argument for the benchmark results that sufficiently offsets the pain PGO inflicts. Is there? http://graphs.mozilla.org/graph.html#tests=[[83,94,12],[83,1,12]]sel=nonedisplayrange=365datatype=running Ts, Paint shows an improvement of 14%. This is with Firefox and Firefox-Non-PGO, which I believe to be mc. Also while I can't seem to find it on pertastic, Tresize appears to enjoy a 9% improvement with pgo on mc. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
