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 Ru

Re: What platform features can we kill?

On Wed, Oct 9, 2013 at 2:36 PM, Ehsan Akhgari 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 ow

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 > Engineerin

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

Re: What platform features can we kill?

On Wed, Oct 9, 2013 at 4:28 PM, Philipp Kewisch 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 sho

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 qu

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

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 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

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 ou

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 failur

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

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 th

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

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 i

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 yo

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

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 a

Re: Migrating to Win64 rev2 machines

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,

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 anyt

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: We also use it for about:memory apparently. ___

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

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 thi

Re: What platform features can we kill?

On Wed, Oct 9, 2013 at 9:01 AM, Gervase Markham 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

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

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 har

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 deskt

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

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. _

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?

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 st

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

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: W

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

Re: Extensibility of JavaScript modules

I am interested, although my buglist is rather full. What kind of help would be useful? On Wed Oct 9 19:03:06 2013, Jason Orendorff wrote: > 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 imp

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 bui

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 pl

Re: What platform features can we kill?

On Wed, Oct 9, 2013 at 9:01 AM, Gervase Markham 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 f

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 i

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

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 tha

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

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:

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 t

Re: Poll: What do you need in MXR/DXR?

I'd like to see: - carrying over the line numbers from the URL to the blame link On Oct 2, 2013, at 9:43 PM, Benoit Jacob wrote: > - DXR permanent code links i.e. code links to a particular hg changeset, > not to "tip", so that I can paste code links on a bug and they stay valid. > Currently I fa

Re: Poll: What do you need in MXR/DXR?

Nicholas Nethercote wrote: On Wed, Oct 9, 2013 at 1:49 AM, Neil 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

Re: Poll: What do you need in MXR/DXR?

On Wed, Oct 9, 2013 at 1:49 AM, Neil 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 unt

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 e