Re: Audit your code if you use mozilla::WeakPtr
On 10/8/13 10:32 PM, Justin Dolske wrote: Would that be a kungFuDeathGrep? (Sorry. Just making weak pun.) You mean mozilla::WeakpPunT? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Poll: What do you need in MXR/DXR?
On 10/02/2013 12:33 PM, Erik Rose wrote: What features do you most use in MXR and DXR? (Apologies for the late reply; didn't really check newsgroups during the summit - bad wifi and having too much to do. Didn't about the design session in SC for the same reason.) I look up XPCOM interfaces a lot; as an example, http://dxr.mozilla.org/mozilla-central/search?q=nsIObserverService doesn't seem very useful - the actual interface definition is near the bottom. The various type/function/whatever forms in the advanced search just returns nothing. (Other than the path search, of course, but not all interfaces are files named after them.) The equivalent webidl search would be something like http://dxr.mozilla.org/mozilla-central/search?q=HTMLBaseElement (type:HTMLBaseElement finds no results). ++ on unifying identifier search (across types of identifiers), tree switching, blame integration, rev pinning, etc - things already covered by the wiki. (In roughly that order.) HTH, -- Mook (now with a face XD ) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ Standards Committee meeting next week
On 10/02/2013 06:06 PM, Botond Ballo wrote: Having to repeat 'expr' is rather unfortunate, and C++14 fixes that. You can now write: auto function(A a, B b) { return expr; } The only restriction is that if there are multiple return expressions, they must all have the same type. Same type as in the std::is_same sense? Or same type in the a?b:c sense, where b/c can be different types, and one expression must convert to the other's type? I assume you mean the former, but I can imagine cases (think pointers and nullptr) where the latter would definitely be nice. Jeff ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Poll: What do you need in MXR/DXR?
On Wed, Oct 9, 2013 at 1:49 AM, Neil n...@parkwaycc.co.uk wrote: Nor can I seem to get regexp search to work; I never get any results. If you're using the regexp field in the advanced search, you're probably failing to put '/' (or some other delimiter) at the start and end. I too was having trouble with this until very recently. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Poll: What do you need in MXR/DXR?
Nicholas Nethercote wrote: On Wed, Oct 9, 2013 at 1:49 AM, Neil n...@parkwaycc.co.uk wrote: Nor can I seem to get regexp search to work; I never get any results. If you're using the regexp field in the advanced search, you're probably failing to put '/' (or some other delimiter) at the start and end. I too was having trouble with this until very recently. Thanks, that made regexp: search work for me. -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Supporting the Windows Certificate Store
On Wednesday, January 9, 2013 12:17:12 PM UTC-5, joshu...@gmail.com wrote: I know that there are probably well thought out reasons that this isn't a features already...BUT! Lot's of US Government users can't use Firefox because it doesn't use the Windows certificate store. Months late to this party, but I do not believe there is a well-thought-out reason why Firefox does not support the MS certificate store. There are rationalizations, certainly, and those who make them probably feel they are justified--but the bottom line is that Chrome, Safari, and IE all support MS' native certificate store, and so should Firefox. In this case, yes: if all the other lemmings are jumping off the cliff, so should Firefox. Make it opt-in if necessary, but make it happen. That way end users won't have to dick around with multiple certificate stores in order to use Firefox, and the developers can feel they're maintaining their principled, if esoteric, stand. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Poll: What do you need in MXR/DXR?
Better python support. For example, the function name parameter doesn't work with ext: .py http://dxr.mozilla.org/mozilla-central/search?q=function%3Astart%20ext%3A.py -- no results http://dxr.mozilla.org/mozilla-central/search?q=%22def%20start%22%20ext%3A.py -- results On 10/02/2013 03:33 PM, Erik Rose wrote: What features do you most use in MXR and DXR? Over in the recently renamed Web Engineering group, we're working hard to retire MXR. It hasn't been maintained for a long time, and there's a lot of duplication between it and DXR, which rests upon a more modern foundation and has been developing like crazy. However, there are some holes we need to fill before we can expect you to make a Big Switch. An obvious one is indexing more trees: comm-central, aurora, etc. And we certainly have some bothersome UI bugs to squash. But I'd like to hear from you, the actual users, so it's not just me and Taras guessing at priorities. What keeps you off DXR? (What are the MXR things you use constantly? Or the things which are seldom-used but vital?) If you're already using DXR as part of your workflow, what could it do to make your work more fun? Feel free to reply here, or attach a comment to this blog post, which talks about some of the things we've done recently and are considering for the future: https://blog.mozilla.org/webdev/2013/09/30/dxr-gets-faster-hardware-vcs-integration-and-snazzier-indexing/ We'll use your input to build our priorities for Q4, so wish away! Cheers, Erik ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
What platform features can we kill?
Attack surface reduction works: http://blog.gerv.net/2013/10/attack-surface-reduction-works/ Removing E4X broke the NSA's EGOTISTICALGOAT attack - a type confusion vulnerability in E4X. In the spirit of learning from this, what's next on the chopping block? A quick survey of the security-group led to the following suggestions, and I'm sure there are more: * JS engine: Proxy.create, Object.prototype.watch, __noSuchMethod__, legacy (pre-ES6) generators, __iterator__, non-ES6 let-blocks, pre-ES6 expression closures * Editor (share a JS implementation with Servo instead) * Most OOM recovery in the JS engine * FTP (perhaps replace with JS implementation from FireFTP) * Windows integrated auth * XSLT (Chrome have already announced they will remove it: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/zIg2KC7PyH0 ; https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/k8aIeI6BCG0 ) Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On 10/9/13 12:01 PM, Gervase Markham wrote: In the spirit of learning from this, what's next on the chopping block? RDF * XSLT (Chrome have already announced they will remove it: We'd need to do the same extension thing they're proposing or something; this is used in the wild for sites that people care about. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On 10/9/2013 12:18 PM, Boris Zbarsky wrote: On 10/9/13 12:01 PM, Gervase Markham wrote: In the spirit of learning from this, what's next on the chopping block? RDF I'm all for this, although the risk is probably quite small because we don't expose RDF to content. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Extensibility of JavaScript modules
On 10/8/13 4:27 PM, David Rajchenbach-Teller wrote: That sounds quite sufficient for me. Do we have plans to backport Cu.import to ES6 modules? No plans yet. Want to work on it with us? We're not ready to start just now, but parser support for ES6 modules is being added, and the self-hosted implementation of Loader is underway at https://github.com/jorendorff/js-loaders. -j ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On Wed, Oct 9, 2013 at 9:01 AM, Gervase Markham g...@mozilla.org wrote: * Windows integrated auth I would love to kill Windows integrated auth. It seems like doing so would mean almost the same thing as saying we don't care about intranets though. That's something I would be very interested in hearing about from the Product team. We should remove the legacy window.crypto.* (MOZ_DOMCRYPTO_LEGACY) stuff described at [1]. (Warning: The features mentioned in this article are proprietary Mozilla extensions, and are not supported in any other browser.) I am working on sorting out the politics of doing so on dev-tech-crypto [2]. [1] https://developer.mozilla.org/en-US/docs/JavaScript_crypto [2] https://groups.google.com/d/msg/mozilla.dev.tech.crypto/FRmpYubnan4/DDiAtniVW-0J Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On 09.10.2013 18:01, Gervase Markham wrote: * XSLT (Chrome have already announced they will remove it: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/zIg2KC7PyH0 ; https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/k8aIeI6BCG0 CON to remove XSLT support from platform! XML/XSLT is used for printing ICS calendar data to get web page output in form of agenda/dairy lists. This is the most flexible form a user can get for his/her requirements. All can be configured by the user outside of the extension code! Removing XSLT would remove this flexibility. Not good ;( ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On 10/9/13 9:49 AM, Benjamin Smedberg wrote: In the spirit of learning from this, what's next on the chopping block? RDF I'm all for this, although the risk is probably quite small because we don't expose RDF to content. Bug 833098 - Kick RDF out of Firefox Comments in the bug suggest a build-time flag because Thunderbird needs on RDF. chris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On 9/10/13 17:18, Boris Zbarsky wrote: On 10/9/13 12:01 PM, Gervase Markham wrote: In the spirit of learning from this, what's next on the chopping block? * XSLT (Chrome have already announced they will remove it: Have they? I admit I haven't made it through every post in their discussion threads, but AFAICS, some people from Chrome have expressed an interest in removing it, but this suggestion generated considerable debate (including some definite opposition to the idea). We'd need to do the same extension thing they're proposing or something; this is used in the wild for sites that people care about. It's used in the wild on the web, and I've also known it to be used locally as a convenient tool to present views of data files that happen to be maintained in XML format. Moving it to an extension (so that it isn't available unless the user is aware of it and explicitly installs support) would seem like a negative step, though if usage is rare/specialized enough, perhaps it would be OK. But I think we should be very hesitant to entirely remove XSLT support from the platform. JK ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On 2013-10-09 12:18 PM, Boris Zbarsky wrote: On 10/9/13 12:01 PM, Gervase Markham wrote: In the spirit of learning from this, what's next on the chopping block? RDF We use RDF in Firefox, in localstore.rdf among others I guess. * XSLT (Chrome have already announced they will remove it: We'd need to do the same extension thing they're proposing or something; this is used in the wild for sites that people care about. We use XSLT in our products in a few places I guess, including http://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/content/extensions.xml#l1373 :( Also, note that I don't think the Blink folks have reached a consensus on whether they can remove XSLT or not yet. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On 2013-10-09 12:01 PM, Gervase Markham wrote: * Editor (share a JS implementation with Servo instead) I've been fantacizing about this for a while (not about the Servo code sharing part per se of course.) This is hard because of a variety of reasons, including the fact that there is no real spec for editing. But I've also heard recent rumors that the Blink people want their editing code out of their core code as well... So it would be interesting to keep watching this space. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On 10/9/13 2:25 PM, Ehsan Akhgari wrote: On 2013-10-09 12:18 PM, Boris Zbarsky wrote: On 10/9/13 12:01 PM, Gervase Markham wrote: In the spirit of learning from this, what's next on the chopping block? RDF We use RDF in Firefox, in localstore.rdf among others I guess. Right. We should stop doing that. ;) -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
Gervase Markham wrote: * XSLT Doesn't the XML prettyprinter use XSLT? -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
Gervase Markham wrote: * Editor (share a JS implementation with Servo instead) By the time the editor works in Servo, you probably want to think about reducing your attack surface by switching to Servo instead. -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On 10/9/13 11:29 AM, Boris Zbarsky wrote: RDF We use RDF in Firefox, in localstore.rdf among others I guess. Right. We should stop doing that. ;) Bug 559505 - localstore.rdf kills ponies I got hung up on the (ancient) patch there because RDF is baked pretty firmly into the XUL Tree API. (Hey, I just thought of another thing to add to the chopping block.) Justin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Shumway UX
Hi All: I hope everyone had a chance to see Shumway on the big screen at the Summit. I'm very proud of what the Shumway team has accomplished to date. While the demos looked amazing, we've got quite a bit to do to get Shumway to a product-ready state. In particular, the user experience on desktop and mobile need focused design and integration work to get right. The integration with other Firefox features (eg. click-to-play) also needs special consideration. I'm preparing some mock-ups of some ideas I have re: UX based on my own observations and experiences with both Shumway and the Adobe Flash Player. I should have these ready to share by the end of the week. I'm not alone in thinking about the problems to solve here, and I'd like to get the discussion going on this thread. Please share your own experiences/concerns/ideas. We meet every Thursday at 11:00AM Pacific. Please join us on the #shumway IRC channel to get the meeting details. Thanks, --Jet ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On 10/9/2013 2:25 PM, Ehsan Akhgari wrote: On 2013-10-09 12:18 PM, Boris Zbarsky wrote: On 10/9/13 12:01 PM, Gervase Markham wrote: In the spirit of learning from this, what's next on the chopping block? RDF We use RDF in Firefox, in localstore.rdf among others I guess. This is not that hard to fix. AFAIK there's nothing that intrinsically ties XUL persistence to localstore.rdf, and we already have an import library for RDF written in JS. So it's mainly a question of hooking XUL persistence up to something simpler (probably storage). --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Shumway UX
During the Thursday, October 17th meeting, we will have guest stars Mary Trombley and IIana Segall from User Research joining us to share their findings from the Flash CTP research project they conducted earlier this year. (I'll send out a reminder next week). Erin On Oct 9, 2013, at 12:05 PM, Jet Villegas j...@mozilla.com wrote: Hi All: I hope everyone had a chance to see Shumway on the big screen at the Summit. I'm very proud of what the Shumway team has accomplished to date. While the demos looked amazing, we've got quite a bit to do to get Shumway to a product-ready state. In particular, the user experience on desktop and mobile need focused design and integration work to get right. The integration with other Firefox features (eg. click-to-play) also needs special consideration. I'm preparing some mock-ups of some ideas I have re: UX based on my own observations and experiences with both Shumway and the Adobe Flash Player. I should have these ready to share by the end of the week. I'm not alone in thinking about the problems to solve here, and I'd like to get the discussion going on this thread. Please share your own experiences/concerns/ideas. We meet every Thursday at 11:00AM Pacific. Please join us on the #shumway IRC channel to get the meeting details. Thanks, --Jet ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On Wed, Oct 9, 2013 at 9:01 AM, Gervase Markham g...@mozilla.org wrote: Attack surface reduction works: http://blog.gerv.net/2013/10/attack-surface-reduction-works/ In the spirit of learning from this, what's next on the chopping block? Master password. The UI is prone to phishing, it causes all sorts of problems because of how we use the log in to the NSS database to implement it, it causes annoying UX for the people that use it, the cryptography used is useless (bing FireMaster), there's hardly any resources to do anything to actually fix any of these problems other than remove it, and it slows down progress on important security features. Cheers, Brian ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On 10/9/13 6:18 PM, Boris Zbarsky wrote: On 10/9/13 12:01 PM, Gervase Markham wrote: In the spirit of learning from this, what's next on the chopping block? RDF Yes. I think that localstore.rdf is the long pole. Not so much because we abuse it for xul persistance, that's OK to fix. The thing that bothers me most is all of those addons that probably still use it. I'd love if we could get some data about that in particular, and RDF usage in addons in general. And then there's mailnews, of course. That one's sad. Close, but we moved everyone off of mailnews just before it got rid of RDF, IIRC. Axel ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Migrating to Win64 rev2 machines
Release Engineering is migrating the Windows 64-bit _build_ machines to a new, managed machine image which will decrease the amount of administrative overhead needed to deploy new instances, make image changes, etc. It uses the same build toolchain as the current Windows 64-bit images (MSVC10) but located at different paths so you'll notice conditional checks like http://hg.mozilla.org/mozilla-central/file/a141e39bf6da/build/win64/mozconfig.vs2010#l2 which will be uplifted. The 'cedar' project branch has been building successfully using the new image. The plan is to migrate other branches over the next few weeks in this order: - remaining project branches - mozilla-central - mozilla-inbound, b2g-inbound - try - aurora - beta - release, mozilla-b2g18* - esr Wait times may increase for a short time on days that we cut over to the new build machines (since we are reimaging existing machines in chunks). We'll be keeping an eye on those wait times and adjusting the number of machines cut over if needed. Thunderbird comm-* branches will be cut over at the same time as their mozilla-* counterpart. The project branches will be cut over tomorrow and we'll let those build over the weekend before cutting over mozilla-central. I will send an email notification on this thread before and after a cutover so everyone knows the current status. Bug 781277 tracks this effort. If you have any questions or concerns, please let me know. Thanks, John ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On 2013-10-09 2:39 PM, Neil wrote: Gervase Markham wrote: * XSLT Doesn't the XML prettyprinter use XSLT? It does: http://mxr.mozilla.org/mozilla-central/source/content/xml/document/resources/XMLPrettyPrint.xsl?force=1 We also use it for about:memory apparently. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
Master password. The UI is prone to phishing, it causes all sorts of problems because of how we use the log in to the NSS database to implement it, it causes annoying UX for the people that use it, the cryptography used is useless (bing FireMaster), there's hardly any resources to do anything to actually fix any of these problems other than remove it, and it slows down progress on important security features. I use master password. Is there something I can use instead that's more secure? Thanks, Botond ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Migrating to Win64 rev2 machines
Hey Jet, I'd say that this greenery project is completely aside from the work John is doing -- build and tests machines are generally separate. Are you looking for you (or someone else) to have access to a machine to green up tests on your own, or looking to have tests run as part of the normal automation (or maybe on Try?)? - Ben On 10/09/13 05:35 PM, Jet Villegas wrote: I'm currently looking for someone to green up the tests on Win64. Can we dedicate one machine instance (I'm assuming this is on AWS?) for the purpose of advancing this greenery project? Also, who is the point-person on Release Engineering that we should pull into the testing discussion? Thanks, --Jet - Original Message - From: John Hopkins jhopk...@mozilla.com To: dev.platform dev-platform@lists.mozilla.org Cc: sheri...@mozilla.com Sent: Wednesday, October 9, 2013 2:22:52 PM Subject: Migrating to Win64 rev2 machines Release Engineering is migrating the Windows 64-bit _build_ machines to a new, managed machine image which will decrease the amount of administrative overhead needed to deploy new instances, make image changes, etc. It uses the same build toolchain as the current Windows 64-bit images (MSVC10) but located at different paths so you'll notice conditional checks like http://hg.mozilla.org/mozilla-central/file/a141e39bf6da/build/win64/mozconfig.vs2010#l2 which will be uplifted. The 'cedar' project branch has been building successfully using the new image. The plan is to migrate other branches over the next few weeks in this order: - remaining project branches - mozilla-central - mozilla-inbound, b2g-inbound - try - aurora - beta - release, mozilla-b2g18* - esr Wait times may increase for a short time on days that we cut over to the new build machines (since we are reimaging existing machines in chunks). We'll be keeping an eye on those wait times and adjusting the number of machines cut over if needed. Thunderbird comm-* branches will be cut over at the same time as their mozilla-* counterpart. The project branches will be cut over tomorrow and we'll let those build over the weekend before cutting over mozilla-central. I will send an email notification on this thread before and after a cutover so everyone knows the current status. Bug 781277 tracks this effort. If you have any questions or concerns, please let me know. Thanks, John ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Extensibility of JavaScript modules
On 10/9/13 12:56 PM, David Rajchenbach-Teller wrote: I am interested, although my buglist is rather full. What kind of help would be useful? When it's time, we'll need to: 1. write Loader hooks to make the `import` keyword behave like Cu.import 2. somehow have those hooks installed by default in every chrome window And maybe: 3. migrate existing Cu.import call sites to ES6 `import` 4. reimplement Cu.import and friends on top of the Loader API But I'm not sure 3 and 4 are possible. ES6 modules are designed for the web and so are inherently asynchronous. Cu.import is synchronous. Switching poses some risks. -j ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Poll: What do you need in MXR/DXR?
Thanks, everyone, for your thoughtful and voluminous input! I bequeath you the following behind-the-scenes links so you can see the effect your feedback is having on DXR's future. We've collected, de-duped, and categorized your feedback at https://wiki.mozilla.org/DXR_UI_Refresh#Feedback. If you see your request grossly mischaracterized or omitted, feel free to edit. I'm watching the page. I've done a first cut at immediate goals just above that, at https://wiki.mozilla.org/DXR_UI_Refresh#Plans_And_Priorities. Finally, there's a rough draft at a revised (and more sensical) query syntax up at https://github.com/erikrose/dxr/blob/query-parser/docs/queries.rst. This is just the beginning. I'll be posting updates at https://blog.mozilla.org/webdev/tag/dxr/ whenever there's something useful to say, and you can watch the DXR_UI_Refresh wiki page if you want more frequent updates. Cheers, Erik ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Migrating to Win64 rev2 machines
I think we could have it happen in this order: 1. a way to green up tests on a single machine hooked up to a build server 2. put this on Try 3. put this on production automation Of course, it would be awesome if we could skip #1 and go to #2 directly as we green up the tests, as this will open it up to multiple contributors for the test greening. --Jet - Original Message - From: Ben Hearsum bhear...@mozilla.com To: dev-platform@lists.mozilla.org Sent: Wednesday, October 9, 2013 2:50:52 PM Subject: Re: Migrating to Win64 rev2 machines Hey Jet, I'd say that this greenery project is completely aside from the work John is doing -- build and tests machines are generally separate. Are you looking for you (or someone else) to have access to a machine to green up tests on your own, or looking to have tests run as part of the normal automation (or maybe on Try?)? - Ben On 10/09/13 05:35 PM, Jet Villegas wrote: I'm currently looking for someone to green up the tests on Win64. Can we dedicate one machine instance (I'm assuming this is on AWS?) for the purpose of advancing this greenery project? Also, who is the point-person on Release Engineering that we should pull into the testing discussion? Thanks, --Jet - Original Message - From: John Hopkins jhopk...@mozilla.com To: dev.platform dev-platform@lists.mozilla.org Cc: sheri...@mozilla.com Sent: Wednesday, October 9, 2013 2:22:52 PM Subject: Migrating to Win64 rev2 machines Release Engineering is migrating the Windows 64-bit _build_ machines to a new, managed machine image which will decrease the amount of administrative overhead needed to deploy new instances, make image changes, etc. It uses the same build toolchain as the current Windows 64-bit images (MSVC10) but located at different paths so you'll notice conditional checks like http://hg.mozilla.org/mozilla-central/file/a141e39bf6da/build/win64/mozconfig.vs2010#l2 which will be uplifted. The 'cedar' project branch has been building successfully using the new image. The plan is to migrate other branches over the next few weeks in this order: - remaining project branches - mozilla-central - mozilla-inbound, b2g-inbound - try - aurora - beta - release, mozilla-b2g18* - esr Wait times may increase for a short time on days that we cut over to the new build machines (since we are reimaging existing machines in chunks). We'll be keeping an eye on those wait times and adjusting the number of machines cut over if needed. Thunderbird comm-* branches will be cut over at the same time as their mozilla-* counterpart. The project branches will be cut over tomorrow and we'll let those build over the weekend before cutting over mozilla-central. I will send an email notification on this thread before and after a cutover so everyone knows the current status. Bug 781277 tracks this effort. If you have any questions or concerns, please let me know. Thanks, John ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Migrating to Win64 rev2 machines
On 10/09/13 06:29 PM, Jet Villegas wrote: I think we could have it happen in this order: 1. a way to green up tests on a single machine hooked up to a build server 2. put this on Try 3. put this on production automation Of course, it would be awesome if we could skip #1 and go to #2 directly as we green up the tests, as this will open it up to multiple contributors for the test greening. Single dedicated machines aren't really a thing for us, so #1 isn't actually doable. While research what it would take to do #2 I noticed that we already have 64-bit Windows tests running over on the Date branch! I'm not fully in the loop on this, but I believe this was revived within the last couple of months. Results are over here: https://tbpl.mozilla.org/?tree=Date We could probably make it possible to run them on Try, but I should defer to Chris AtLee or John Hopkins at this point, as they've got much more context on this than me. - Ben ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Migrating to Win64 rev2 machines
On 10/09/13 06:49 PM, Ben Hearsum wrote: We could probably make it possible to run them on Try, but I should defer to Chris AtLee or John Hopkins at this point, as they've got much more context on this than me. OK, one more reply from: These _are_ enabled on Try, but the try syntax to use them is undocumented. Pushing with try: -b o -p win64 -u all[win64_vm] -t none should get you a full suite of tests. You can also use the normal subselection by replacing all with reftest or similar. - Ben ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On 10/9/13 6:01 PM, Gervase Markham wrote: Attack surface reduction works: http://blog.gerv.net/2013/10/attack-surface-reduction-works/ Removing E4X broke the NSA's EGOTISTICALGOAT attack - a type confusion vulnerability in E4X. In the spirit of learning from this, what's next on the chopping block? So you are saying, we should start removing features that could decrease the attack surface? So then lets remove JavaScript, this could definitely decrease the attack surface. I think its the wrong conclusion, shouldn't we rather be fixing security holes and analysing the code for vulnerabilities than removing random things just because of their potential risk? Removing features will definitely make people unhappy, and more work for (extension) authors needing to adapt to the platform changes yet again. Philipp ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Migrating to Win64 rev2 machines
Excellent. Now to find willing volunteer(s.) Windows 64 represents a key platform for us now that we've opened up Firefox for high-performance graphics via WebGL and Canvas. Freeing up the CPU by going to the GPU exposes the next bottleneck: Memory Bandwidth. Can you help get the test failures fixed? Please reply to me if you can contribute here. Thanks, --Jet - Original Message - From: Ben Hearsum bhear...@mozilla.com To: dev-platform@lists.mozilla.org Sent: Wednesday, October 9, 2013 4:15:04 PM Subject: Re: Migrating to Win64 rev2 machines On 10/09/13 06:49 PM, Ben Hearsum wrote: We could probably make it possible to run them on Try, but I should defer to Chris AtLee or John Hopkins at this point, as they've got much more context on this than me. OK, one more reply from: These _are_ enabled on Try, but the try syntax to use them is undocumented. Pushing with try: -b o -p win64 -u all[win64_vm] -t none should get you a full suite of tests. You can also use the normal subselection by replacing all with reftest or similar. - Ben ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On 10/09/2013 12:37 PM, Chris Peterson wrote: On 10/9/13 9:49 AM, Benjamin Smedberg wrote: In the spirit of learning from this, what's next on the chopping block? RDF I'm all for this, although the risk is probably quite small because we don't expose RDF to content. Bug 833098 - Kick RDF out of Firefox Comments in the bug suggest a build-time flag because Thunderbird needs on RDF. Thunderbird doesn't really want RDF either. However, killing RDF in Thunderbird has been a slow process. If there's anyone who wants to help kill RDF in Thunderbird, go for it! - Jim ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Migrating to Win64 rev2 machines
Did we start caring about Win64 again recently? +bsmedberg - Kyle On Wed, Oct 9, 2013 at 7:33 PM, Jet Villegas j...@mozilla.com wrote: Excellent. Now to find willing volunteer(s.) Windows 64 represents a key platform for us now that we've opened up Firefox for high-performance graphics via WebGL and Canvas. Freeing up the CPU by going to the GPU exposes the next bottleneck: Memory Bandwidth. Can you help get the test failures fixed? Please reply to me if you can contribute here. Thanks, --Jet - Original Message - From: Ben Hearsum bhear...@mozilla.com To: dev-platform@lists.mozilla.org Sent: Wednesday, October 9, 2013 4:15:04 PM Subject: Re: Migrating to Win64 rev2 machines On 10/09/13 06:49 PM, Ben Hearsum wrote: We could probably make it possible to run them on Try, but I should defer to Chris AtLee or John Hopkins at this point, as they've got much more context on this than me. OK, one more reply from: These _are_ enabled on Try, but the try syntax to use them is undocumented. Pushing with try: -b o -p win64 -u all[win64_vm] -t none should get you a full suite of tests. You can also use the normal subselection by replacing all with reftest or similar. - Ben ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On 10/9/2013 11:18 AM, Boris Zbarsky wrote: On 10/9/13 12:01 PM, Gervase Markham wrote: In the spirit of learning from this, what's next on the chopping block? RDF Having gone through some of the ancient security bugs, it looks like the walking-security-hole aspect of RDF was limited mostly to mailnew's horrific abuse of it for folders. That aspect I have a plan to eliminate; the use of it for templated UI is, too my knowledge, not a security issue per se. Also, to those who believe that localstore.rdf is the only use of RDF remaining in Firefox, I can only cock my head and laugh. MXR reveals that charsets, mimetypes, and help (which is in toolkit, but may only be in SeaMonkey these days) are still present uses in mozilla-central. And I'm sure that a significant number of addons still use it. (I'd refer you to an MXR results for addons, but this is the sort of thing where it fails miserably since it doesn't let me search only addons that work on maintained versions of Firefox). -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On 2013-10-09 12:01 PM, Gervase Markham wrote: In the spirit of learning from this, what's next on the chopping block? In between keep the C++ implementation and scrap entirely is reimplement in JS, and I think that should be seriously considered for things like XSLT where there's no question but what it increases our attack surface, but there is also a strong (if small) constituency. Where it is currently impossible to do something in JS, that points at a weakness in the platform - whether capabilities or just speed. In that vein, I think we should take a hard look at the image decoders. Not only is that a significant chunk of attack surface, it is a place where it's hard to innovate; image format after image format has died on the vine because it wasn't *enough* of an improvement to justify the additional glob of compiled code. Web-deliverable JS image decoders could open that up. The other thing that comes to mind is, if Web Components lives up to its promise, perhaps it could be used for the built-in form controls? That's also a big pile of hair, and form elements in odd places have been an ongoing source of crasher bugs. zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On Wed, Oct 9, 2013 at 4:28 PM, Philipp Kewisch mozi...@kewis.ch wrote: I think its the wrong conclusion, shouldn't we rather be fixing security holes and analysing the code for vulnerabilities than removing random things just because of their potential risk? Those options are not mutually exclusive; we should be doing both. There's obvious value in thinking about ways to reduce our attack surface, and that's all Gerv was suggesting we do. Obviously there are tradeoffs involved, and we need to evaluate them when making any decisions. Arguing that removing anything would be equivalent to removing support for JS is not really useful. I don't think anyone in this thread was actually mistaken into thinking that removing RDF or XSLT was as simple as an hg rm. That removing them is harder than that doesn't mean it's not worth thinking about (and indeed much thinking about it has been done, in e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=833098). Gavin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On 10/9/13 8:36 PM, Zack Weinberg wrote: if Web Components lives up to its promise, perhaps it could be used for the built-in form controls? For what it's worth, we've tried that with XBL. It died on the performance and memory usage beach... -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Migrating to Win64 rev2 machines
Hi, Jet: On 13-10-09 5:35 PM, Jet Villegas wrote: I'm currently looking for someone to green up the tests on Win64. Can we dedicate one machine instance (I'm assuming this is on AWS?) for the purpose of advancing this greenery project? Also, who is the point-person on Release Engineering that we should pull into the testing discussion? This switchover is specifically for the build machines, not test machines. You probably want bug 886640. Thanks, John - Original Message - From: John Hopkins jhopk...@mozilla.com To: dev.platform dev-platform@lists.mozilla.org Cc: sheri...@mozilla.com Sent: Wednesday, October 9, 2013 2:22:52 PM Subject: Migrating to Win64 rev2 machines Release Engineering is migrating the Windows 64-bit _build_ machines to a new, managed machine image which will decrease the amount of administrative overhead needed to deploy new instances, make image changes, etc. It uses the same build toolchain as the current Windows 64-bit images (MSVC10) but located at different paths so you'll notice conditional checks like http://hg.mozilla.org/mozilla-central/file/a141e39bf6da/build/win64/mozconfig.vs2010#l2 which will be uplifted. The 'cedar' project branch has been building successfully using the new image. The plan is to migrate other branches over the next few weeks in this order: - remaining project branches - mozilla-central - mozilla-inbound, b2g-inbound - try - aurora - beta - release, mozilla-b2g18* - esr Wait times may increase for a short time on days that we cut over to the new build machines (since we are reimaging existing machines in chunks). We'll be keeping an eye on those wait times and adjusting the number of machines cut over if needed. Thunderbird comm-* branches will be cut over at the same time as their mozilla-* counterpart. The project branches will be cut over tomorrow and we'll let those build over the weekend before cutting over mozilla-central. I will send an email notification on this thread before and after a cutover so everyone knows the current status. Bug 781277 tracks this effort. If you have any questions or concerns, please let me know. Thanks, John ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On Wed, Oct 9, 2013 at 2:36 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: In the spirit of learning from this, what's next on the chopping block? JSD. Firebug's the main consumer, AFAIK. * Most OOM recovery in the JS engine In the past that has been left alone due to the preference of the JS engine module owner. Perhaps the new JS engine module owners can say what they think about it. * XSLT We also use it for about:memory apparently. We do? Can you show me where? In that vein, I think we should take a hard look at the image decoders. At the summit a few of us were talking about ways to promote Rust. One idea was to rewrite a smallish, well-separated component of Firefox in Rust, to (a) gain the benefits (parallelism, safety) of Rust, and (b) promote Rust as a credible language in non-experimental systems. Image decoders were the first component that came up as a possibility. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On Wed, Oct 09, 2013 at 08:18:16PM -0700, Nicholas Nethercote wrote: At the summit a few of us were talking about ways to promote Rust. One idea was to rewrite a smallish, well-separated component of Firefox in Rust, to (a) gain the benefits (parallelism, safety) of Rust, and (b) promote Rust as a credible language in non-experimental systems. Image decoders were the first component that came up as a possibility. The problem with that plan is that bootstrapping the rust compiler is kind of a problem at the moment, both for trusting trust, and for shipping in e.g. linux distros. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform